The Semantic Business Process Management (SPBM) approach from the SUPER project utilizes a Semantic Execution Environment (SEE) for the automatic discovery, composition, mediation, and invocation of Web services. In order to enable the Semantic Execution Environment, an engineer must create semantic descriptions of functional, nonfunctional, and behavioural aspects of Web services and enduser requirements. In this paper we introduce MEMOS, a methodology for modeling services that provides a detailed description of the di erent activities, tasks, roles, and artifacts that exist within a Semantic Web Service (SWS) engineering project, from both a service provider and service requester perspective. By introducing the rst methodology for Semantic Web Services, we aim to support engineers in their development projects, ultimately improving quality, reducing cost, and enabling the adoption of Semantic Web Services at large.
D.2 [Software Engineering]: Interoperability; D.2.10 [Design]: Methodologies
Business Process Management (BPM) is an established discipline whereby the processes of a company are modelled, monitored, managed, and adapted according to business experts' viewpoint, well-separated from the lower-level IT concerns associated with their realisation. Meanwhile the approach of Service-Oriented Architecture (SOA) has made Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
SBPM ’10 Crete, Greece
Copyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$10.00.
strides towards supporting the requirements of agile
crossorganisational business processes at this implementation level.
Semantic Business Process Management (SBPM) [
Semantic Web Services (SWS) represent the next evolutionary step forward in Service Oriented Computing, namely the addition of ontology-based semantic descriptions for each service, comprising a formal description of the services functionality, non functional aspects, and external behaviour. Once services are described semantically, many of the tasks involved in using them can be automated and real dynamism can be added to applications using the Semantically-enabled SOA paradigm. SWS have reached a maturity level where there is a shared understanding within the research community, which is supported by conceptual models, languages, and tools and there is considerable interest in the use of SWS as a technology for enabling the dynamic discovery, composition, mediation, and invocation of Web services. However, the barrier to the adoption of this new technology is its complexity and a lack of understanding of which activities need to be performed in order to achieve successful results.
In order to achieve this meeting between di erent
communities beyond the sphere of research it is necessary to
concretely and methodically describe the results and shared
understanding of 7 years research and development in SWS.
In particular the conceptual models, languages, frameworks,
and tools must be placed in the context of methodologies,
best practices, and guidelines. The introduction of
methodological support for SWS will enable engineers to receive the
consistency of action [
We begin this paper by giving a brief overview of SBPM
and SWS (Section 2) and then summarize our preliminary
analysis of how SWS are currently being used in the SBPM
community from [
To support the separation of business analysts' and IT
viewpoints of business processes the SUPER project has
introduced two main ontologies: the Business Process Modelling
Ontology (BPMO)1 and a Semantic BPEL model, which is
grounded for execution to a compliant extended WS-BPEL
2.0 schema, BPEL4SWS [
BPMO's stated intention is to \[model] business processes
at the semantic level, integrating knowledge about the
organisational context, work ow activities and Semantic Web
Services." The work ow aspect is conceptualised via the
abstractions encoded in Work ow Patterns [
The Web Service Modeling Ontology (WSMO) [
WSMO's service model is primarily used in two regards
in BPMO. The concept of goal allows the requirements for
external tasks to be functionally speci ed, along with
nonfunctional requirements related to, for instance, Quality of
Service. The concept of mediator allows both the speci
cation of necessary data mediation within a process, as well as
a mediation process to be speci ed between a set of processes
that are otherwise lacking in mutual conformance. In
translation to Semantic BPEL mediators are intended to play the
same role [
A number of other conceptual models and languages
exist for semantically describing services, including OWL-S
[
Alternate link via post-SUPER pre-standardisation activity
in STI Conceptual Models for Services Working Group:
http://cms-wg.sti2.org/reports/
exist within a SSOA inspired by existing models and
languages. Transformations from this reference ontology to and
from OWL-S, WSMO, and WSMO-Lite have also been
dened in [
In [
Scenario 1a: Capability-based Service Advertisement: In this scenario the provider creates a functional description of the service to be advertised in the form of a capability description. Similarly, the service requester provides a capability description of their functional need. Matches are found by comparing the requesters capability description against provider capability descriptions.
Scenario 1b: Mediator-based Service Advertisement: In this scenario mediators are used to de ne matches between service descriptions and goal descriptions. These matches are de ned at design time and thus the process of discovery is a simple lookup of a mediator. Mediator-based discovery is especially suitable in an environment where the number of services is limited.
Scenario 2: Using the SSOA-RO for Service Invocation: In a di erent context the services needed within a system may already be known, so no discovery is necessary; however automatic invocation of these services may be needed, particularly in cases where service interfaces change regularly. There are two ways in which service invocation can occur: Scenario 2a: Service Choreography-based Invocation: The provider creates a process model, entitled a choreography, that describes the external behavior of their service, i.e. how the requester should interact with the service. The choreography is accompanied by a grounding that enables ontological instances to be sent to the service according to a particular data schema. The requester need only provide the relevant ontological instances to invoke the service. Scenario 2b: Goal Choreography-based Invocation: Scenario 2a is only possible in cases where all the information needed to execute the service choreography is available prior to the execution. If new data needs to be generated based on the responses from the service, then the requester also requires a choreography such that a conversation between the requester and provider can be made.
Scenario 3: Using the SSOA-RO for Service Composition: Scenario 1 enables the automatic discovery of services; however, it is often the case that no single service can ful l a requesters goal description. In such a case it may be possible to combine a number of services in order to ful l the requesters requirements. There are two approaches to service composition: Scenario 3a: Design-time Service Composition: Some actor manually creates a new service description containing an orchestration, which brings together individual service and goal descriptions to deliver a composite functionality. This scenario can be combined with scenarios 1 or 2 so that this service description can be automatically discovered or invoked.
Scenario 3b: Run-time Service Composition: An orchestration of service descriptions is created automatically to ful l a goal description. The composition process is enduser-guided, through the speci cation of a capability description, non functional preferences, a target choreography, or a partial orchestration.
Scenario 4: Engineering Ontologies in the SSOARO Context: Scenarios 1, 2, and 3 require ontologies to enable service and goal descriptions to be created. While engineers should use existing ontology engineering methodologies, the following scenarios should be considered in the ontology engineering process: Scenario 4a: Engineering Ontologies from a Data Schema: Using the provider or requesters data schema, e.g. the XML Schema of a SOAP Web service, as input to the ontology engineering process makes it easier to create a grounding for the resulting ontology; however no shared understanding with other parties exists and heterogeneity issues must be resolved later.
Scenario 4b: Reusing Existing Ontologies: Reusing existing ontologies to describe service and goal descriptions results in few heterogeneity issues between requesters and providers, but the process of creating a grounding becomes more complicated due to the potential gap between the data schema used by the provider or requester, and the reused ontologies.
Scenario 4c: Reengineering Existing Ontologies: Existing ontologies are reengineered taking into account the provider or requester data schema. Creating a grounding is more complex than in 4a and more heterogeneity exists than in 4b, but better than the worst case in both.
Scenario 5: Enabling Interoperation Between Ontologies: Using scenarios 4a and 4c results in ontologies that are locally relevant but not shared with others in the community. Discovery, invocation, and composition in scenarios 1, 2, and 3 will not function correctly unless the ontologies used by requesters and providers are aligned. Therefore, to enable interoperability between requester goal descriptions and provider service descriptions it is necessary to de ne an ontology to ontology mediator (ooMediator), between the ontologies that they use. An ooMediator is usually accompanied by a mapping document containing mappings between the di erent elements in the source and target ontologies. 4.
The Methodology for Modeling Services (MEMOS) provides
a systematic approach to the implementation of Semantic
Web Services using the SSOA-RO by de ning the speci c
activities and tasks that must be performed by particular
actors in each of the phases of the Software Development
Cycle (SDC). The methodology is designed considering the
di erent scenarios in which Semantic Web Services are
currently being used by the community, as described in Section
3. The MEMOS activities and tasks are de ned in a
Software Development Process Model (SDPM) independent way
such that they can be combined into a process with activities
and tasks from other methodologies, for example the OASIS
FWSI Web Service Implementation Methodology [
MEMOS is structured around the Software Development
Cycle and de nes activities that should be conducted in the
context of the requirements, design, implementation,
testing, and installation & checkout phases of the Software Life
Cycle (SLC) as de ned by the IEEE in [
MEMOS is made up of 28 activities, which are in turn
made up of 94 individual tasks with accompanying
guidelines, an overview of which can be seen in Figure 2. The
tasks are performed by 14 roles including usual software
engineering roles, for example requirements analyst, designer,
and domain expert, and those speci c to SWS development,
namely ontology engineer, semantic service engineer, and
mapping engineer. Due to space restrictions it is not possible
to describe all 94 MEMOS tasks in detail, thus in the
following sections we provide an overview of each of the MEMOS
activities and summarize the tasks within them. A full
description of all activities and tasks can be found in [
The requirements phase is made up of 7 activities and aims to solicit requirements from stakeholders and domain experts regarding the problem to be solved: Activity R1 - Identify the Need: The aim of this activity is to discover the exact problem that needs to be solved by the development project. The requirements analyst begins by identifying the stakeholder and the relevant domain experts needed in this process and goes on to elicit a problem statement from these individuals. Once a problem statement exists the requirements analyst should identify those scenarios from section 3 needed to solve the problem and nally gather the knowledge sources from the domain expert needed in the requirements phase, for example service or application design documentation, WSDL documents, and XML Schemas.
Activity R2 - Gather Functional Requirements: If scenario 1 is identi ed during activity R1 then the requirements analyst should gather requirements related to the functional aspects of the service description or goal description to be created. In a provider context this involves the requirements analyst understanding the functionality o ered by the Web service, the speci c functionality that the stakeholder wants to advertise, and the discovery broker services where the advertisement will be made. In a requester context the requirements analyst should understand the application in question, determine the functional need that this application has, and the discovery broker services where the stakeholder wants to search for this functionality. Activity R3 - Gather Non Functional Requirements: If scenario 1 is identi ed during activity R1 then the requirements analyst should gather requirements related to the non functional aspects of the service description or the goal description to be created. In a provider context this means understanding the non functional behaviour of the Web service to be described and choosing which of these aspects should be advertised, e.g. availability, security, obligations. In a requester context the requirements analyst should gain an understanding of the non functional aspects which are important to the application that will use services, and identify the importance that the stakeholder assigns to these non functional aspects.
Activity R4 - Gather Behavioral Requirements: If scenario 2 was identi ed during activity R1 then the requirements analyst should gather requirements related to the behavioral aspects of the service description or goal description to be created. In a provider context this means understanding the behaviour of the di erent operations on the Web service, the relationship between them, and the groupings of operations that should be advertised as choreographies. While in a requester context this means identifying the data that is available within the application which could be sent to services, and the data that would be expected as a result of invocation. Activity R5 - Gather Knowledge Requirements: Using the functional, non functional, and behavioral requirements as input, the requirements analyst can begin the process of requirements gathering for the ontologies that will be required to describe the functional, non functional, and behavioral aspects of the service description or goal description to be created. This activity involves the selection of an appropriate ontology engineering methodology and performing the activities from this methodology. The requirements analyst should also work with domain experts to identify those models that are used (or could be used) by potential collaborators and competitors.
Activity R6 - Manage Requirements: In this activity the requirements are checked for consistency and to ensure that they meet the original problem statement from the stakeholder. This activity also includes the identi cation of dependencies between requirements and the assignment of requirement priorities.
Activity R7 - Prepare User Acceptance and System Tests: The aim of this activity is to identify relevant test cases that can be used for system and user acceptance testing in the test phase of the development process. This activity also ensures that all of the requirements identi ed in the requirements speci cation are covered by test cases by creating a validation matrix. 4.2
The design phase is made up of 10 activities, and aims to build a well-organized representation of the set of artifacts needed to meet the gathered requirements.
Activity D1 - De ne High Level Architecture: The
aim of this activity is to de ne the overview architecture of
all the service descriptions and goal descriptions needed to
realize the gathered requirements, along with the ontologies
that they use. The high-level architecture also contains the
mediators that link service descriptions, goal descriptions
and ontologies together, and where necessary the mappings
that enable these mediators. Finally the high level
architecture shows the di erent groundings that are required to
enable interoperability between the SSOA-RO artifacts and
the concrete services or applications they describe. An
example of a providers high level architecture diagram can be
seen in Figure 3, a requesters high level architecture diagram
would look similar, except that it would be centred around
the application with a functional need. An in depth
explanation of Figure 3 can be found in [
Activity D2 - De ne Physical Architecture: In this activity the architect and deployer work together to tie the high level architecture to a physical architecture. The physical architecture speci es the di erent repositories and broker services where the artifacts in the high level architecture will be registered and used. This activity also produces a step-by-step deployment plan, which will be followed in the installation and checkout phase.
Activity D3 - Design Capability Description: In this activity the designer should create a detailed design description for each of the capability descriptions de ned in the high level architecture. This activity involves creating natural language descriptions of each of the preconditions, postconditions, assumptions, and e ects that describe the functionality of the service. The designer should consider the information gathered about the discovery broker service where the capability will be used, as it may ignore service preconditions, or mandate the speci cation of a minimum number of postconditions or e ects, etc.
Activity D4 - Design Non Functional Properties and Preferences: In this activity the designer should create a detailed design of the non-functional properties on each service description and the non functional preferences of each goal description in the high level architecture. This activity involves taking the properties or preferences identi ed in the requirements phase and assigning values to each. In the case of preferences, this activity also involves assigning weights to each of the preferences according to the requesters non functional needs.
Activity D5 - Design Choreography: In this activity the designer should create a detailed design for the choreographies of each of the service descriptions and goal descriptions in the high level architecture. The main output of this activity is a dependency diagram, which captures the different operations on the service, their inputs, their outputs, and the dependencies that exist between them. Choreographies on goal descriptions have a similar diagram except that they capture the requested interface of a Web service rather than that of a real Web service.
Activity D6 - Design Ontology: In this activity the designer is responsible for designing each of the ontologies in the high level architecture according to the ontology engineering methodology selected in the requirements phase. The main job of the engineer in this task is to design the concepts, attributes, relations, axioms, and instances that make up the ontology. The designer should take note of the logical formalism identi ed in the high level architecture for this ontology, as the choice of formalism will have an impact on the design of the ontology, and, a particular ontology may need to be created in more than one formalism in order to support di erent broker services.
Activity D7 - Design Grounding: In this activity the designer should create a design for each of the groundings identi ed in the high level architecture. The dependency graph created in activity D6 contains a clear speci cation of the di erent schema elements that need to be sent and received via the choreography and can be used by the designer to identify those parts of the underlying schema that need to be transformable to and from ontologies. The designer should go on to identify the equivalent ontology elements for each of these schema elements.
Activity D8 - Design Mediators: In this activity the designer should create a list of the sources and targets for each mediator in the high level architecture.
Activity D9 - Design OO Mappings: In this activity the designer should create a design for each of the mapping documents identi ed in the high level architecture. This activity begins by identifying the di erent elements of the source ontology that need to be transformed to the target ontology, utilizing the functional, non functional, and behavioural requirements. The designer should go on to identify discrepancies between source and target data values and design a set of data value transformation services to resolve these discrepancies, e.g. if the values "John" and "Smith" from the source become the value "John Smith" in the target, a service which concatenates the values together would be required.
Activities D3 to D9 also involve the de nition of functional tests for each of the detailed designs created. For example, in the context of capability descriptions this means identifying the requesters capability descriptions that should nd a particular providers capability description, or in the context of OO Mappings the test designer should create pairs of ontology instances from the source and target ontologies, which are equivalent with one another.
Activity D10 - Prepare Integration Tests: While the test cases used for system tests, which were created in activity R7, look at the end-to-end behavior of the artifacts in the system, the test designer should create integration test cases that should focus on how two or more individual artifacts interact. 4.3
In the implementation phase the detailed design of the individual components within the high level architectural design are reduced down to concrete SSOA-RO artifacts. The implementation phase is made up of 7 activities as follows: Activity I1 - Implement Ontology: In this activity the ontology engineer creates an ontology for each of the ontologies in the high-level architecture according to their respective detailed design speci cations, by performing the implementation tasks from the chosen ontology engineering methodology.
Activity I2 - Implement Service Description &
Activity I3 - Implement Goal Description: These activities
involve the reduction of the capability description design,
non functional design, and choreography design down into
concrete implementations for each service description and
goal description in the high level architecture respectively.
Activity I4 - Implement Grounding: In this activity,
lifting and lowering mappings are created to realize each
of the groundings in the high level architecture, according
to the approach used by the targeted broker service. For
example, lifting and lowering broker services exist that are
powered by rules [
Activity I6 - Implement OO Mappings: In this activity
each of the mapping documents in the high level architecture
are created according to the OO mappings design created in
activity D9. [
Activity I7 - Unit Test: The purpose of this activity is to test particular units of functionality in the system of SSOARO artifacts. The semantic service engineer should execute the functional tests de ned in activities D3 to D9 in this activity against the artifacts created in I1 to I6. 4.4
The testing phase ensures that the software designed in the design phase and implemented in the implementation phase meets the requirements laid down in the requirements phase. In the MEMOS methodology it has just a single activity, as much of the work related to testing is performed across the other phases of the development cycle: Activity T1 - Execute Test Plan: Unit testing has been performed in the implementation phase to ensure that the created artifacts function as expected within the development environment. The testing of the artifacts is brought a step further in this activity, with the functional, integration, system, and user acceptance test cases, de ned throughout the development process, being executed in a testing environment that is equivalent to where they will be deployed. 4.5
The installation & checkout phase nalizes the Software Development Cycle and comprises 3 activities, which ensure that the artifacts created in the implementation phase are documented, deployed to the locations where they will be available to end users, and that maintainers are trained in how to maintain these artifacts: Activity IC1 - Document Artifacts: The aim of this activity is to create the documentation needed for end users and maintainers to successfully work with the SSOA-RO artifacts created in the project, including annotations on the artifacts themselves and printed and on-line materials, e.g. user manuals.
Activity IC2 - Install Artifacts: This activity involves the execution of the deployment plan created in D2 such that the created SSOA-RO artifacts are deployed to the locations where they will be available to end users. Crucially this activity also involves the re-execution of the test plan to ensure these artifacts function as expected in the deployment environment.
Activity IC3 - Train Maintainers: The aim of this activity is to train the maintainers, who must maintain the SSOARO artifacts in the deployment environment, such that they have the relevant knowledge to perform their jobs.
A two step approach to the evaluation of the methodology
has been taken, using professional reviews and a case study:
OASIS SEE-TC Professional Review: As we utilized
the SSOA-RO as the main language for describing the
artifacts in the MEMOS methodology, the rst logical place to
conduct professional reviews was within the OASIS SEE-TC
that produced this speci cation. The MEMOS
methodology is currently available as a working draft [
SHAPE Professional Review: Independently the SHAPE
European framework project2, which develops the needed
infrastructure and technology for using the new OMG
Service Oriented Architecture Markup Language (SoaML)
standard [
In this paper we have given a broad overview of a
Methodology for Modeling Services (MEMOS), which de nes the
activities, tasks, artifacts, and roles that exist across the
di erent phases of the Software Development Cycle for
Semantic Web Services. In all there are 28 activities and 94
tasks in the methodology performed by 14 roles. Each of
the tasks is accompanied with detailed guidelines on how to
achieve the best result when performing them. We direct
readers wishing to go into the details of these guidelines to
[
In terms of next steps, additional case studies will be conducted to further test the feasibility, usability, and usefulness of the methodology, and to further hone the guidelines and recommendations that accompany it. The methodology currently supports scenarios 1a, 1b, 2a, 2b, 4a, 4b, 4c, and 5 as de ned in Section 3. In coming versions of the methodology, we will examine the use of orchestrations within the community for enabling service compositions and extend the methodology with support for creating these orchestrations, both at design-time (scenario 3a) and in runtime (scenario 3b). Finally, while the WSMT supports many of the activities and tasks that must be conducted within the methodology, it does not currently guide the roles through the methodology itself. Subsequent versions of the WSMT will be extended in this direction, such that the process of following the methodology can be made easier.
The work is funded by the European Commission under the projects ACTIVE, COIN, LarKC, MUSING, Service Web 3.0, SHAPE, and SOA4ALL.