=Paper=
{{Paper
|id=None
|storemode=property
|title=MEMOS: A Methodology for Modeling Services
|pdfUrl=https://ceur-ws.org/Vol-682/paper3.pdf
|volume=Vol-682
|dblpUrl=https://dblp.org/rec/conf/esws/KerriganNS10
}}
==MEMOS: A Methodology for Modeling Services==
https://ceur-ws.org/Vol-682/paper3.pdf
MEMOS: A Methodology for Modeling Services
Mick Kerrigan Barry Norton Elena Simperl
Semantic Technology Institute Institute AIFB Institute AIFB
University of Innsbruck Karlsruhe Institute of Karlsruhe Institute of
Austria Technology Technology
mick.kerrigan@sti2.at Germany Germany
barry.norton@kit.edu elena.simperl@kit.edu
ABSTRACT strides towards supporting the requirements of agile cross-
The Semantic Business Process Management (SPBM) ap- organisational business processes at this implementation level.
proach from the SUPER project utilizes a Semantic Execu- Semantic Business Process Management (SBPM) [9] is a re-
tion Environment (SEE) for the automatic discovery, com- cent approach based on the application of ontology-based
position, mediation, and invocation of Web services. In or- semantics to bridge the gap between the business analyst’s
der to enable the Semantic Execution Environment, an en- and IT department’s viewpoints in BPM, which is an appli-
gineer must create semantic descriptions of functional, non- cation of the principle of ontological role separation. Many
functional, and behavioural aspects of Web services and end- SBPM approaches use Semantic Web Services (SWS) and
user requirements. In this paper we introduce MEMOS, a semantics-driven execution.
methodology for modeling services that provides a detailed Semantic Web Services (SWS) represent the next evolu-
description of the different activities, tasks, roles, and arti- tionary step forward in Service Oriented Computing, namely
facts that exist within a Semantic Web Service (SWS) en- the addition of ontology-based semantic descriptions for each
gineering project, from both a service provider and service service, comprising a formal description of the services func-
requester perspective. By introducing the first methodol- tionality, non functional aspects, and external behaviour.
ogy for Semantic Web Services, we aim to support engineers Once services are described semantically, many of the tasks
in their development projects, ultimately improving quality, involved in using them can be automated and real dynamism
reducing cost, and enabling the adoption of Semantic Web can be added to applications using the Semantically-enabled
Services at large. SOA paradigm. SWS have reached a maturity level where
there is a shared understanding within the research commu-
nity, which is supported by conceptual models, languages,
Categories and Subject Descriptors and tools and there is considerable interest in the use of SWS
D.2 [Software Engineering]: Interoperability; as a technology for enabling the dynamic discovery, compo-
D.2.10 [Design]: Methodologies sition, mediation, and invocation of Web services. However,
the barrier to the adoption of this new technology is its com-
General Terms plexity and a lack of understanding of which activities need
to be performed in order to achieve successful results.
Human Factors, Design In order to achieve this meeting between different com-
munities beyond the sphere of research it is necessary to
Keywords concretely and methodically describe the results and shared
understanding of 7 years research and development in SWS.
Semantic Web Services, WSMO, Methodology
In particular the conceptual models, languages, frameworks,
and tools must be placed in the context of methodologies,
1. INTRODUCTION best practices, and guidelines. The introduction of method-
Business Process Management (BPM) is an established dis- ological support for SWS will enable engineers to receive the
cipline whereby the processes of a company are modelled, consistency of action [12] that a methodology provides, and
monitored, managed, and adapted according to business ex- improve the quality of the resulting descriptions in terms
perts’ viewpoint, well-separated from the lower-level IT con- of meeting cost estimates, having all of the functionality
cerns associated with their realisation. Meanwhile the ap- promised, and delivering in the right time frame.
proach of Service-Oriented Architecture (SOA) has made 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 [11] (Section 3). In this analysis we iden-
Permission to make digital or hard copies of all or part of this work for tify a set of scenarios for SWS that describe the high-level
personal or classroom use is granted without fee provided that copies are tasks that must be performed by engineers in order to realise
not made or distributed for profit or commercial advantage and that copies each of them, with these scenarios acting as a starting point
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
for the methodology. We then introduce a Methodology for
permission and/or a fee. Modeling Services (MEMOS), which provides a systematic
SBPM ’10 Crete, Greece approach to the implementation of Semantic Web Services
Copyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$10.00.
13
by defining the activities and tasks that must be performed exist within a SSOA inspired by existing models and lan-
by particular actors in each of the phases of the software guages. Transformations from this reference ontology to and
development cycle (Section 4). This methodology has un- from OWL-S, WSMO, and WSMO-Lite have also been de-
dergone evaluation in the form of both professional reviews fined in [6]. Thus in this paper we use the terminology from
and a case study (Section 5), which have highlighted open the SSOA-RO to define the MEMOS methodology such that
issues and motivate our future work (Section 6). it can be applied to WSMO as well as the other models
and languages. The SSOA-RO terminology is introduced
2. BACKGROUND throughout the next section.
To support the separation of business analysts’ and IT view-
points of business processes the SUPER project has intro-
duced two main ontologies: the Business Process Modelling 3. ENGINEERING SCENARIOS FOR
Ontology (BPMO)1 and a Semantic BPEL model, which is SEMANTIC WEB SERVICES
grounded for execution to a compliant extended WS-BPEL In [11], we performed an analysis of recent projects on the
2.0 schema, BPEL4SWS [17]. Common features between topics of Semantic Web Services and Semantic Business Pro-
the two can be mediated using ontology-based rules [18]. cess Management (SBPM), as well as a survey of SWS ex-
BPMO’s stated intention is to “[model] business processes perts, in order to understand how Semantic Web Services
at the semantic level, integrating knowledge about the or- are being used in the community. From this analysis, in [11]
ganisational context, workflow activities and Semantic Web we also defined a set of engineering scenarios that describe
Services.” The workflow aspect is conceptualised via the ab- the high-level tasks that must be performed by engineers in
stractions encoded in Workflow Patterns [21] and aims to order to realise each of them. The benefit of these scenarios
be graphically represented in a fragment of the Business is they can be combined by an engineer in order to design
Process Modelling Notation (BPMN) [19]. The patterns rich and complex systems, while still allowing the engineer to
covered are also intended to abstract over the features of have a clear understanding of the SWS artifacts that must
Event-driven Process Chains (EPCs), the extended model be implemented in order to enable the final system. The
of which in the ARIS toolset is inspiration for the modelling scenarios are a starting point for the MEMOS methodology
of organisational context [20]. and are summarized here in terms of the SSOA-RO, a full
The Web Service Modeling Ontology (WSMO) [8] is a con- description of which can be found in [4]:
ceptual model for Semantic Web Services and has four top
level elements, namely Ontologies, Web Services, Goals and Scenario 1: Using the SSOA-RO for Service Ad-
Mediators. Ontologies are the basis for the other descrip- vertisement: A discovery broker service can be used to
tions by providing the terminology that they use. WSMO find service descriptions advertised by providers based on
Web Services provide a semantic description of both the a requesters goal description. There are two common ap-
function of a service, in terms of a Capability, and the mech- proaches to service discovery, described in the scenarios be-
anism for interacting with it, in terms of an Interface. A low. If service ranking is required in either scenario, providers
WSMO goal allows for the requirements of the requester to should annotate their service descriptions with non func-
be semantically described. Finally, WSMO Mediators pro- tional properties describing the quality of service aspects of
vide a means to resolve heterogeneity issues that inevitably their Web service and requesters should provide their pref-
occur between the other elements due to the open and dis- erences over non functional properties in their goal descrip-
tributed nature of the Web. tions.
WSMO’s service model is primarily used in two regards Scenario 1a: Capability-based Service Advertisement:
in BPMO. The concept of goal allows the requirements for In this scenario the provider creates a functional description
external tasks to be functionally specified, along with non- of the service to be advertised in the form of a capability de-
functional requirements related to, for instance, Quality of scription. Similarly, the service requester provides a capabil-
Service. The concept of mediator allows both the specifica- ity description of their functional need. Matches are found
tion of necessary data mediation within a process, as well as by comparing the requesters capability description against
a mediation process to be specified between a set of processes provider capability descriptions.
that are otherwise lacking in mutual conformance. In trans- Scenario 1b: Mediator-based Service Advertisement:
lation to Semantic BPEL mediators are intended to play the In this scenario mediators are used to define matches be-
same role [16]. Goals, on the other hand, may either be left tween service descriptions and goal descriptions. These mat-
in place for run-time matching to a web service, as described ches are defined at design time and thus the process of dis-
below, or may be replaced with the semantic description of covery is a simple lookup of a mediator. Mediator-based
a suitable service in the executable process. discovery is especially suitable in an environment where the
A number of other conceptual models and languages ex- number of services is limited.
ist for semantically describing services, including OWL-S
[14] and WSMO-Lite [22]. Recently the Reference Ontol- Scenario 2: Using the SSOA-RO for Service Invo-
ogy for Semantic Service Oriented Architectures (SSOA- cation: In a different context the services needed within
RO) [2] was defined in the OASIS Semantic Execution En- a system may already be known, so no discovery is neces-
vironment technical committee (SEE-TC). It provides a un- sary; however automatic invocation of these services may be
ambiguous definition in RDF-S of the different concepts that needed, particularly in cases where service interfaces change
1
Final SUPER version submitted to SBPM. regularly. There are two ways in which service invocation
Alternate link via post-SUPER pre-standardisation activity can occur:
in STI Conceptual Models for Services Working Group: Scenario 2a: Service Choreography-based Invoca-
http://cms-wg.sti2.org/reports/ tion: The provider creates a process model, entitled a chore-
14
ography, that describes the external behavior of their ser- that are locally relevant but not shared with others in the
vice, i.e. how the requester should interact with the service. community. Discovery, invocation, and composition in sce-
The choreography is accompanied by a grounding that en- narios 1, 2, and 3 will not function correctly unless the on-
ables ontological instances to be sent to the service according tologies used by requesters and providers are aligned. There-
to a particular data schema. The requester need only pro- fore, to enable interoperability between requester goal de-
vide the relevant ontological instances to invoke the service. scriptions and provider service descriptions it is necessary to
Scenario 2b: Goal Choreography-based Invocation: define an ontology to ontology mediator (ooMediator), be-
Scenario 2a is only possible in cases where all the informa- tween the ontologies that they use. An ooMediator is usually
tion needed to execute the service choreography is available accompanied by a mapping document containing mappings
prior to the execution. If new data needs to be generated between the different elements in the source and target on-
based on the responses from the service, then the requester tologies.
also requires a choreography such that a conversation be-
tween the requester and provider can be made. 4. MEMOS: A METHODOLOGY FOR MOD-
Scenario 3: Using the SSOA-RO for Service Com-
ELING SERVICES
position: Scenario 1 enables the automatic discovery of The Methodology for Modeling Services (MEMOS) provides
services; however, it is often the case that no single service a systematic approach to the implementation of Semantic
can fulfil a requesters goal description. In such a case it may Web Services using the SSOA-RO by defining the specific
be possible to combine a number of services in order to fulfil activities and tasks that must be performed by particular
the requesters requirements. There are two approaches to actors in each of the phases of the Software Development
service composition: Cycle (SDC). The methodology is designed considering the
Scenario 3a: Design-time Service Composition: Some different scenarios in which Semantic Web Services are cur-
actor manually creates a new service description containing rently being used by the community, as described in Section
an orchestration, which brings together individual service 3. The MEMOS activities and tasks are defined in a Soft-
and goal descriptions to deliver a composite functionality. ware Development Process Model (SDPM) independent way
This scenario can be combined with scenarios 1 or 2 so that such that they can be combined into a process with activities
this service description can be automatically discovered or and tasks from other methodologies, for example the OASIS
invoked. FWSI Web Service Implementation Methodology [3].
Scenario 3b: Run-time Service Composition: An or-
chestration of service descriptions is created automatically
to fulfil a goal description. The composition process is end-
user-guided, through the specification of a capability de-
scription, non functional preferences, a target choreography,
or a partial orchestration.
Scenario 4: Engineering Ontologies in the SSOA-
RO Context: Scenarios 1, 2, and 3 require ontologies to
enable service and goal descriptions to be created. While
engineers should use existing ontology engineering method-
ologies, the following scenarios should be considered in the Figure 1: Relationship between Phases, Activities,
ontology engineering process: Tasks, Roles and Artifacts in MEMOS
Scenario 4a: Engineering Ontologies from a Data
MEMOS is structured around the Software Development
Schema: Using the provider or requesters data schema,
Cycle and defines activities that should be conducted in the
e.g. the XML Schema of a SOAP Web service, as input to
context of the requirements, design, implementation, test-
the ontology engineering process makes it easier to create
ing, and installation & checkout phases of the Software Life
a grounding for the resulting ontology; however no shared
Cycle (SLC) as defined by the IEEE in [1]. Activities in the
understanding with other parties exists and heterogeneity
MEMOS methodology define a collection of common tasks
issues must be resolved later.
that lead towards the output of a particular artifact. In cer-
Scenario 4b: Reusing Existing Ontologies: Reusing
tain activities, particularly in the requirements phase, tasks
existing ontologies to describe service and goal descriptions
within a particular activity are split into provider tasks and
results in few heterogeneity issues between requesters and
requester tasks. Provider tasks are undertaken by service
providers, but the process of creating a grounding becomes
providers as they attempt to expose their services according
more complicated due to the potential gap between the data
to the scenarios defined in section 3. Requester tasks are
schema used by the provider or requester, and the reused on-
similarly performed by those attempting to use Semantic
tologies.
Web Services to fulfil some functional need within an appli-
Scenario 4c: Reengineering Existing Ontologies: Ex-
cation. A task in the MEMOS methodology is a unit of work
isting ontologies are reengineered taking into account the
that contributes to the completion of a given activity and its
provider or requester data schema. Creating a grounding is
output artifact(s). One or more roles perform the task by
more complex than in 4a and more heterogeneity exists than
utilizing the provided input artifacts, according to the spec-
in 4b, but better than the worst case in both.
ified guidelines, to produce the output artifacts. Figure 1
illustrates the relationship between phases, activities, tasks,
Scenario 5: Enabling Interoperation Between On-
roles, and artifacts, which is in-line with the IEEE standard
tologies: Using scenarios 4a and 4c results in ontologies
documentation.
15
Figure 2: Overview of Activities in the MEMOS Methodology
The methodology aims to support SWS engineers and aid nally gather the knowledge sources from the domain expert
them to realize system that use scenarios 1, 2, 4, and 5 as de- needed in the requirements phase, for example service or
scribed in Section 3. The pace at which the different SWS application design documentation, WSDL documents, and
artifacts have been adopted and used to date in the com- XML Schemas.
munity varies, and this is especially true for orchestrations. Activity R2 - Gather Functional Requirements: If
Thus service composition (scenario 3) is deemed out of scope scenario 1 is identified during activity R1 then the require-
for this version of the methodology and will be added later ments analyst should gather requirements related to the
when the community has more experience. It should also be functional aspects of the service description or goal descrip-
noted that a large amount of effort has been spent within the tion to be created. In a provider context this involves the
ontology engineering community developing methodologies requirements analyst understanding the functionality offered
for creating, reusing, and reengineering ontologies. While by the Web service, the specific functionality that the stake-
the MEMOS methodology has tasks in each of the relevant holder wants to advertise, and the discovery broker services
software development cycle phases related to the develop- where the advertisement will be made. In a requester con-
ment of ontologies, these tasks are delegated to an appro- text the requirements analyst should understand the appli-
priate ontology engineering methodology, which is selected cation in question, determine the functional need that this
during the requirements gathering phase. application has, and the discovery broker services where the
MEMOS is made up of 28 activities, which are in turn stakeholder wants to search for this functionality.
made up of 94 individual tasks with accompanying guide- Activity R3 - Gather Non Functional Requirements:
lines, an overview of which can be seen in Figure 2. The If scenario 1 is identified during activity R1 then the require-
tasks are performed by 14 roles including usual software en- ments analyst should gather requirements related to the non
gineering roles, for example requirements analyst, designer, functional aspects of the service description or the goal de-
and domain expert, and those specific to SWS development, scription to be created. In a provider context this means
namely ontology engineer, semantic service engineer, and understanding the non functional behaviour of the Web ser-
mapping engineer. Due to space restrictions it is not possible vice to be described and choosing which of these aspects
to describe all 94 MEMOS tasks in detail, thus in the follow- should be advertised, e.g. availability, security, obligations.
ing sections we provide an overview of each of the MEMOS In a requester context the requirements analyst should gain
activities and summarize the tasks within them. A full de- an understanding of the non functional aspects which are
scription of all activities and tasks can be found in [4]. important to the application that will use services, and iden-
tify the importance that the stakeholder assigns to these non
4.1 Requirements Phase functional aspects.
Activity R4 - Gather Behavioral Requirements: If
The requirements phase is made up of 7 activities and aims
scenario 2 was identified during activity R1 then the require-
to solicit requirements from stakeholders and domain ex-
ments analyst should gather requirements related to the be-
perts regarding the problem to be solved:
havioral aspects of the service description or goal description
to be created. In a provider context this means understand-
Activity R1 - Identify the Need: The aim of this activ-
ing the behaviour of the different operations on the Web
ity is to discover the exact problem that needs to be solved
service, the relationship between them, and the groupings
by the development project. The requirements analyst be-
of operations that should be advertised as choreographies.
gins by identifying the stakeholder and the relevant domain
While in a requester context this means identifying the data
experts needed in this process and goes on to elicit a prob-
that is available within the application which could be sent
lem statement from these individuals. Once a problem state-
to services, and the data that would be expected as a result
ment exists the requirements analyst should identify those
of invocation.
scenarios from section 3 needed to solve the problem and fi-
16
Figure 3: Example of a Providers High Level Architecture Diagram
Activity R5 - Gather Knowledge Requirements: Us- that they use. The high-level architecture also contains the
ing the functional, non functional, and behavioral require- mediators that link service descriptions, goal descriptions
ments as input, the requirements analyst can begin the pro- and ontologies together, and where necessary the mappings
cess of requirements gathering for the ontologies that will that enable these mediators. Finally the high level archi-
be required to describe the functional, non functional, and tecture shows the different groundings that are required to
behavioral aspects of the service description or goal descrip- enable interoperability between the SSOA-RO artifacts and
tion to be created. This activity involves the selection of an the concrete services or applications they describe. An ex-
appropriate ontology engineering methodology and perform- ample of a providers high level architecture diagram can be
ing the activities from this methodology. The requirements seen in Figure 3, a requesters high level architecture diagram
analyst should also work with domain experts to identify would look similar, except that it would be centred around
those models that are used (or could be used) by potential the application with a functional need. An in depth expla-
collaborators and competitors. nation of Figure 3 can be found in [4].
Activity R6 - Manage Requirements: In this activ- Activity D2 - Define Physical Architecture: In this
ity the requirements are checked for consistency and to en- activity the architect and deployer work together to tie the
sure that they meet the original problem statement from the high level architecture to a physical architecture. The phys-
stakeholder. This activity also includes the identification of ical architecture specifies the different repositories and bro-
dependencies between requirements and the assignment of ker services where the artifacts in the high level architecture
requirement priorities. will be registered and used. This activity also produces a
Activity R7 - Prepare User Acceptance and System step-by-step deployment plan, which will be followed in the
Tests: The aim of this activity is to identify relevant test installation and checkout phase.
cases that can be used for system and user acceptance test- Activity D3 - Design Capability Description: In this
ing in the test phase of the development process. This ac- activity the designer should create a detailed design de-
tivity also ensures that all of the requirements identified in scription for each of the capability descriptions defined in
the requirements specification are covered by test cases by the high level architecture. This activity involves creating
creating a validation matrix. natural language descriptions of each of the preconditions,
postconditions, assumptions, and effects that describe the
4.2 Design Phase functionality of the service. The designer should consider
The design phase is made up of 10 activities, and aims to the information gathered about the discovery broker service
build a well-organized representation of the set of artifacts where the capability will be used, as it may ignore service
needed to meet the gathered requirements. preconditions, or mandate the specification of a minimum
number of postconditions or effects, etc.
Activity D1 - Define High Level Architecture: The Activity D4 - Design Non Functional Properties and
aim of this activity is to define the overview architecture of Preferences: In this activity the designer should create a
all the service descriptions and goal descriptions needed to detailed design of the non-functional properties on each ser-
realize the gathered requirements, along with the ontologies
17
vice description and the non functional preferences of each Activity D10 - Prepare Integration Tests: While the
goal description in the high level architecture. This activity test cases used for system tests, which were created in ac-
involves taking the properties or preferences identified in the tivity R7, look at the end-to-end behavior of the artifacts
requirements phase and assigning values to each. In the case in the system, the test designer should create integration
of preferences, this activity also involves assigning weights test cases that should focus on how two or more individual
to each of the preferences according to the requesters non artifacts interact.
functional needs.
Activity D5 - Design Choreography: In this activity 4.3 Implementation Phase
the designer should create a detailed design for the chore- In the implementation phase the detailed design of the indi-
ographies of each of the service descriptions and goal descrip- vidual components within the high level architectural design
tions in the high level architecture. The main output of this are reduced down to concrete SSOA-RO artifacts. The im-
activity is a dependency diagram, which captures the dif- plementation phase is made up of 7 activities as follows:
ferent operations on the service, their inputs, their outputs,
and the dependencies that exist between them. Choreogra- Activity I1 - Implement Ontology: In this activity
phies on goal descriptions have a similar diagram except that the ontology engineer creates an ontology for each of the
they capture the requested interface of a Web service rather ontologies in the high-level architecture according to their
than that of a real Web service. respective detailed design specifications, by performing the
Activity D6 - Design Ontology: In this activity the implementation tasks from the chosen ontology engineering
designer is responsible for designing each of the ontologies methodology.
in the high level architecture according to the ontology en- Activity I2 - Implement Service Description & Activ-
gineering methodology selected in the requirements phase. ity I3 - Implement Goal Description: These activities
The main job of the engineer in this task is to design the involve the reduction of the capability description design,
concepts, attributes, relations, axioms, and instances that non functional design, and choreography design down into
make up the ontology. The designer should take note of the concrete implementations for each service description and
logical formalism identified in the high level architecture for goal description in the high level architecture respectively.
this ontology, as the choice of formalism will have an impact Activity I4 - Implement Grounding: In this activity,
on the design of the ontology, and, a particular ontology may lifting and lowering mappings are created to realize each
need to be created in more than one formalism in order to of the groundings in the high level architecture, according
support different broker services. to the approach used by the targeted broker service. For
Activity D7 - Design Grounding: In this activity the example, lifting and lowering broker services exist that are
designer should create a design for each of the groundings powered by rules [13], XSLT mappings [7], while others exist
identified in the high level architecture. The dependency that require a specific Java class to be written [7].
graph created in activity D6 contains a clear specification of Activity I5 - Implement Mediator: This is a relatively
the different schema elements that need to be sent and re- trivial activity, with each of the mediators specified in the
ceived via the choreography and can be used by the designer high-level architecture being created and linking to the re-
to identify those parts of the underlying schema that need spective source and target SSOA-RO artifacts.
to be transformable to and from ontologies. The designer Activity I6 - Implement OO Mappings: In this activity
should go on to identify the equivalent ontology elements each of the mapping documents in the high level architecture
for each of these schema elements. are created according to the OO mappings design created in
Activity D8 - Design Mediators: In this activity the activity D9. [15] defines two approaches to creating map-
designer should create a list of the sources and targets for ping documents. In the bottom-up approach, the engineer
each mediator in the high level architecture. starts by creating mappings between the most primitive on-
Activity D9 - Design OO Mappings: In this activity tological concepts in the source and target ontologies, which
the designer should create a design for each of the mapping act as a minimal agreement between these ontologies upon
documents identified in the high level architecture. This which more complex mappings can be made. Intuitively the
activity begins by identifying the different elements of the top-down approach starts with the engineer creating map-
source ontology that need to be transformed to the target pings for the more complex ontological concepts first and
ontology, utilizing the functional, non functional, and be- then drilling down to map the less complex ontological con-
havioural requirements. The designer should go on to iden- cepts as necessary.
tify discrepancies between source and target data values and Activity I7 - Unit Test: The purpose of this activity is to
design a set of data value transformation services to resolve test particular units of functionality in the system of SSOA-
these discrepancies, e.g. if the values ”John” and ”Smith” RO artifacts. The semantic service engineer should execute
from the source become the value ”John Smith” in the tar- the functional tests defined in activities D3 to D9 in this
get, a service which concatenates the values together would activity against the artifacts created in I1 to I6.
be required.
Activities D3 to D9 also involve the definition of func- 4.4 Testing Phase
tional tests for each of the detailed designs created. For ex-
The testing phase ensures that the software designed in the
ample, in the context of capability descriptions this means
design phase and implemented in the implementation phase
identifying the requesters capability descriptions that should
meets the requirements laid down in the requirements phase.
find a particular providers capability description, or in the
In the MEMOS methodology it has just a single activity, as
context of OO Mappings the test designer should create
much of the work related to testing is performed across the
pairs of ontology instances from the source and target on-
other phases of the development cycle:
tologies, which are equivalent with one another.
Activity T1 - Execute Test Plan: Unit testing has been
18
performed in the implementation phase to ensure that the MEMOS is generally applicable to service modeling and can
created artifacts function as expected within the develop- be easily adapted to new conceptual models and languages,
ment environment. The testing of the artifacts is brought a in this case SoaML. Feedback from these engineers regard-
step further in this activity, with the functional, integration, ing the methodology has been very positive and their sug-
system, and user acceptance test cases, defined throughout gestions have been used to improve the guidelines associated
the development process, being executed in a testing envi- with MEMOS tasks. Future case study activities plan in the
ronment that is equivalent to where they will be deployed. SHAPE project will act as further evaluation of the appli-
cation of the MEMOS methodology in the SoaML context.
4.5 Installation & Checkout Phase
Case Study: A first case study was recently conducted
The installation & checkout phase finalizes the Software De- with a group of three Semantic Web Service experts, who
velopment Cycle and comprises 3 activities, which ensure had all developed Semantic Web Services before, and who
that the artifacts created in the implementation phase are are experts in the areas of functional descriptions, non func-
documented, deployed to the locations where they will be tional descriptions, and behavioural descriptions respectively.
available to end users, and that maintainers are trained in The tourism domain was selected for the use case, and the
how to maintain these artifacts: experts were asked to act on behalf of a service provider
to advertise a hotel and car booking Web service using the
Activity IC1 - Document Artifacts: The aim of this MEMOS Methodology. The case study was conducted over
activity is to create the documentation needed for end users the course of a week, with the experts using WSMO as the
and maintainers to successfully work with the SSOA-RO ar- conceptual model for developing the service descriptions,
tifacts created in the project, including annotations on the and completing an experience report for each of the activi-
artifacts themselves and printed and on-line materials, e.g. ties and tasks in the methodology as they performed them.
user manuals. The experts were given a requirements and design document
Activity IC2 - Install Artifacts: This activity involves for the Web service they needed to describe, along with the
the execution of the deployment plan created in D2 such WSDL description of that Web service, and access to the
that the created SSOA-RO artifacts are deployed to the lo- domain expert who developed it. The experts felt that the
cations where they will be available to end users. Crucially activities and tasks in the requirements phase were easy to
this activity also involves the re-execution of the test plan conduct and that the resulting requirements specification
to ensure these artifacts function as expected in the deploy- contained all the information needed to perform the rest of
ment environment. the development project. Where they experienced difficulty
Activity IC3 - Train Maintainers: The aim of this activ- was in the design of the high level architecture, due to its
ity is to train the maintainers, who must maintain the SSOA- size and complexity. They suggested that this issue could
RO artifacts in the deployment environment, such that they be resolved through the addition of tools to support this
have the relevant knowledge to perform their jobs. activity. The implementation tasks were relatively trivial
for them to perform given their previous experience, how-
5. EVALUATION ever they stated that the guidelines provided with the im-
A two step approach to the evaluation of the methodology plementation activities are a useful resource for those with
has been taken, using professional reviews and a case study: less experience. The experts used the Web Service Mod-
eling Toolkit (WSMT) [10], an integrated development en-
OASIS SEE-TC Professional Review: As we utilized vironment for Semantic Web Services through the WSMO
the SSOA-RO as the main language for describing the arti- paradigm, throughout the implementation and installation
facts in the MEMOS methodology, the first logical place to & checkout phases. The saw the availability of these tools
conduct professional reviews was within the OASIS SEE-TC as crucial to the successful completion of the activities in
that produced this specification. The MEMOS methodol- these phases. Overall, the participants clearly stated that
ogy is currently available as a working draft [4] within the the MEMOS methodology was useful, could be feasibly ap-
SEE-TC and has received useful feedback from the mem- plied within a development project, and that they believed
bers of this technical committee, who are all experts in the that the availability of such a methodology would improve
field of Semantic Web Services. This feedback has enabled the consistency and repeatability of development of Seman-
the improvement of activities and tasks in the methodol- tic Web Services. The experience reports generated by the
ogy, and their associated guidelines. In the coming months experts led to the addition of a number of new tasks to the
the MEMOS methodology working draft will be voted on methodology, as well as the improvement of the guidelines
by SEE-TC members in order to create a committee draft, for particular tasks.
which will act as a supporting document to the SSOA-RO
specification.
SHAPE Professional Review: Independently the SHAPE
6. CONCLUSIONS
European framework project2 , which develops the needed In this paper we have given a broad overview of a Method-
infrastructure and technology for using the new OMG Ser- ology for Modeling Services (MEMOS), which defines the
vice Oriented Architecture Markup Language (SoaML) stan- activities, tasks, artifacts, and roles that exist across the
dard [5], has adopted the MEMOS methodology as their different phases of the Software Development Cycle for Se-
methodology for engineering SWS in the SoaML context. mantic Web Services. In all there are 28 activities and 94
By integrating the activities and tasks from MEMOS into tasks in the methodology performed by 14 roles. Each of
the SHAPE methodology, the engineers have shown that the tasks is accompanied with detailed guidelines on how to
achieve the best result when performing them. We direct
2
http://www.shape-project.eu readers wishing to go into the details of these guidelines to
19
[4]. It should also be noted that the methodology is sup- [9] M. Hepp, F. Leymann, J. Domingue, A. Wahler, and
ported by development tools in the form of the Web Service D. Fensel. Semantic business process management: A
Modeling Toolkit (WSMT) [10], an integrated development vision towards using semantic web services for
environment for modeling services semantically. business process management. In Proceedings of IEEE
In terms of next steps, additional case studies will be con- Intl. Conf. on e-Business Engineering (ICEBE 2005),
ducted to further test the feasibility, usability, and useful- pages 535–540. IEEE Computer Society, 2005.
ness of the methodology, and to further hone the guidelines [10] M. Kerrigan, A. Mocan, M. Tanler, and D. Fensel.
and recommendations that accompany it. The methodol- The Web Service Modeling Toolkit - An Integrated
ogy currently supports scenarios 1a, 1b, 2a, 2b, 4a, 4b, Development Environment for Semantic Web Services.
4c, and 5 as defined in Section 3. In coming versions of In Proc. of the 4th European Semantic Web Conf.
the methodology, we will examine the use of orchestrations (ESWC2007), June 2007.
within the community for enabling service compositions and [11] M. Kerrigan, B. Norton, E. Simperl, and D. Fensel.
extend the methodology with support for creating these or- Semantic Web Service Engineering for Semantic
chestrations, both at design-time (scenario 3a) and in run- Business Process Management. In Proc. of the 4th
time (scenario 3b). Finally, while the WSMT supports many Intl. workshop on Semantic Business Process
of the activities and tasks that must be conducted within the Management (SBPM), June 2009.
methodology, it does not currently guide the roles through [12] H. Kerzner. Strategic Planning for Project
the methodology itself. Subsequent versions of the WSMT Management using a Project Management Maturity
will be extended in this direction, such that the process of Model. John Wiley & Sons, 2001.
following the methodology can be made easier. [13] D. Lambert and J. Domingue. Grounding Semantic
Web Services with Rules. In Proc. of the 5th
Acknowledgements Workshop on Semantic Web Applications and
The work is funded by the European Commission under the Perspectives (SWAP2008), Dec 2008.
projects ACTIVE, COIN, LarKC, MUSING, Service Web [14] D. Martin. OWL-S: Semantic Markup for Web
3.0, SHAPE, and SOA4ALL. Services. Member Submission 22 November 2004,
W3C, Available from
7. REFERENCES http://www.w3.org/Submission/OWL-S/.
[1] Glossary of Software Engineering Terminology (IEEE [15] A. Mocan and E. Cimpian. Mappings Creation Using
Standard 610.12-1990), 1990. Available from a View Based Approach. In Proc. of the 1st Intl.
http://ieeexplore.ieee.org/xpls/abs all.jsp?arnumber= Workshop on Mediation in Semantic Web Services
159342. (Mediate-2005), Dec 2005.
[2] OASIS Committee Draft 1, Reference Ontology for [16] J. Nitzsche and B. Norton. Ontology-based data
Semantic Service Oriented Architecture Version 1.0. mediation in BPEL (for semantic web services).
November 2008. Available from http://docs.oasis- LNCS. Springer, 2008.
open.org/semantic-ex/ro-soa/v1.0/see-rosoa-v1.0.pdf. [17] J. Nitzsche, T. van Lessen, D. Karastoyanova, and
[3] OASIS Committee Draft 1, Web Service F. Leymann. BPEL for semantic web services
Implementation Methodology. 2005. Available from (BPEL4SWS). In Proceedings of 3rd International
http://www.oasis- Workshop on Agents and Web Services in Distributed
open.org/committees/documents.php?wg abbrev=fwsi. Environments (AWeSome’07), volume 4806 of LNCS.
[4] OASIS Working Draft, Modeling Services with the Springer, 2007.
Reference Ontology for Semantic Service Oriented [18] B. Norton, L. Cabral, and J. Nitzsche. Ontology-based
Architecture 0.1. November 2009. Available from translation of business process models. In Proceedings
http://www.oasis- of 4th International Conference on Internet and Web
open.org/committees/document.php?document id= Applications and Services (ICIW 2009, to appear).
35702. IEEE Computer Society, 2009.
[5] Service Oriented Architecture Modeling Language [19] Object Management Group. Business process
(SoaML), Object Management Group. November modelling notation (BPMN) specification. Technical
2008. Available from report, Object Management Group, 2006.
http://www.omgwiki.org/SoaML/. http://www.omg.org/docs/dtc/06-02-01.pdf.
[6] L. Cabral, M. Kerrigan, and B. Norton. D14.1 [20] A. Scheer, T. Oliver, and A. Otmar. Process modelling
Evaluation Design and Collection of Test Data for using event-driven process chains. In M. Dumas,
Semantic Web Service Tools. Semantic Evaluation At W. van der Aalst, and A. H. M. ter Hofstede, editors,
Large Scale (SEALS) framework project Process-Aware Information Systems, chapter 5, pages
(FP7-238975), 2009. 117–166. Wiley, 2005.
[7] F. Facca, S. Komazec, and I. Toma. WSMX 1.0: A [21] W. van der Aalst, A. ter Hofstede, B. Kiepuszewski,
Further Step toward a Complete Semantic Execution and A. Barros. Workflow patterns. Distributed and
Environment. In Proc. of the 6th European Semantic Parallel Databases, 14(3):5–51, July 2003.
Web Conf. (ESWC 2009), Jun 2009. [22] T. Vitvar, J. Kopecky, J. Viskova, and D. Fensel.
[8] D. Fensel, H. Lausen, A. Polleres, J. de Bruijn, WSMO-Lite Annotations for Web Services. In Proc.
M. Stollberg, D. Roman, and J. Domingue. Enabling of the 5th European Semantic Web Conf. 2008
Semantic Web Services – The Web Service Modeling (ESWC 2008), June 2008.
Ontology. Springer, 2006.
20