ATHABASCA UNIVERSITY

FEATURE-ORIENTED DOMAIN ANALYSIS

FOR SEMANTIC WEB SERVICES

BY

LISA JULIETTE COX

An essay submitted in partial fulfillment

Of the requirements for the degree of

MASTER OF SCIENCE in INFORMATION SYSTEMS

Athabasca, Alberta

December, 2010

© Lisa Juliette Cox, 2010

ATHABASCA UNIVERSITY

The undersigned certify that they have read and recommend for acceptance the integrated project “FEATURE-ORIENTED DOMAIN ANALYSIS FOR SEMANTIC WEB

SERVICES” submitted by LISA JULIETTE COX in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE in INFORMATION SYSTEMS.

______

Dragan Gaševi, Ph.D.

Supervisor

______

Ebrahim Bagheri, Ph.D.

Supervisor

Date: ______

DEDICATION

To Dominique and Zachary

i

ABSTRACT

Interoperability continues to be an open research challenge in the healthcare domain. The lack of interoperability means that information is fragmented across healthcare information silos, hindering integration and effective collaboration between e-health systems, timely access to complete patient medical data and efficiency in healthcare delivery, which are associated with ongoing concerns for patient safety and the cost and quality of healthcare. Information technology needs to be exploited in healthcare to facilitate collaboration between e-health entities’ business processes, enabling access to complete patient medical information, up-to-date drug information and other relevant decision-support systems, thereby enhancing patient safety and reducing or preventing incidences of adverse drug events (ADEs). The main objective of this research is to define a methodology that can be applied to the e-health domain to achieve improvements in interoperability, integration and communication between distributed e- health entities towards reducing incidences of preventable ADEs, which is within the scope of an e-prescription sub-domain. Our proposed methodology is hinged on domain analysis, in particular feature-oriented domain analysis (FODA), in which features which can be seen as concepts and relationships of domain ontologies are linked to conceptual services which direct the design and development of interoperable semantic Web services. Model Driven Development is combined with ontologies in an integrated

Service-Oriented Product Line (SOPL) implementation to transform conceptual services into concrete realizations of semantic Web services for improved interoperability and business process automation. Our proposed methodology is - Feature-Oriented Domain ii

Analysis for Semantic Web services (FODA4SWS), which is illustrated with an e- prescription case study.

iii

ACKNOWLEDGEMENTS

I would like to thank my two supervisors - Dr. Dragan Gaševi and Dr. Ebrahim Bagheri for their guidance and patience throughout my work on this essay, to the staff and faculty of Master of Science in Information Systems (MScIS) and School of Computing and

Information Systems (SCIS) at Athabasca University for their support and to the examining committee for their comments on how to further improve this essay. I would also like to thank my mother and aunt for being there for my family, my husband - my rock, who truly understands how hard it was to keep going at times and that “even the strongest have their moments of fatigue” and to my children Dominique and Zachary who had to deal with so much at such a young age. Without your support and understanding, this essay would not have been possible. Thank You!

iv

TABLE OF CONTENTS

CHAPTER 1 - INTRODUCTION ...... 1

RESEARCH OBJECTIVES and APPROACH ...... 7

ORGANIZATION OF ESSAY ...... 8

CHAPTER 2 - LITERATURE REVIEW ...... 9

SOFTWARE PRODUCT LINE (SPL) ...... 10

Domain Engineering ...... 15

Domain Analysis ...... 16

Feature-Oriented Domain Analysis (FODA) ...... 18

Feature Model ...... 21

SPL Contribution ...... 24

SOFTWARE DEVELOPMENT ...... 25

MODEL DRIVEN DEVELOPMENT (MDD) ...... 25

MDD Contribution ...... 33

SERVICE-ORIENTED ARCHITECTURE (SOA) ...... 33

Core SOA Principles ...... 36

SOA Capabilities ...... 42

Benefits and Challenges of SOA ...... 43

SOA Contribution ...... 45

Service Modeling with SoaML ...... 46

Web Services ...... 51

v

Web Service Architecture Stack ...... 54

BUSINESS PROCESS MANAGEMENT (BPM) ...... 63

Business Process Modeling...... 64

BPM Contribution ...... 69

THE SEMANTIC WEB ...... 70

Semantic Web Services...... 74

OWL-S ...... 76

Semantic Web Services Framework (SWSF) ...... 78

WSDL-S ...... 79

SAWSDL ...... 79

Stack of Ontologies ...... 82

WSMO ...... 83

WSMO Execution Environment (WSMX) ...... 87

The Semantic Web Contribution ...... 88

INTEGRATING KEY TECHNOLOGIES ...... 88

SOA/SPL...... 88

SPL/MDD ...... 89

MDE Integration with other technologies...... 90

SPL/BPM ...... 92

SOA/BPM ...... 92

Integration with Ontologies ...... 95

ODM (Ontology Definition Metamodel) ...... 95

Integrating Ontologies in Software Development ...... 97 vi

E-HEALTH PROBLEM DOMAIN ...... 105

SUMMARY ...... 113

CHAPTER 3 - METHODOLOGY ...... 115

FODA4SWS Methodology Overview ...... 117

Domain Engineering ...... 121

CIM to PIM Transformation ...... 121

PIM to PIM Transformation ...... 122

PIM to PSM Transformation ...... 124

Application Engineering ...... 125

TOOL SUPPORT ...... 126

CHAPTER 4 - RESULTS and ANALYSIS ...... 130

E-PRESCRIPTION (e-Rx) CASE STUDY ...... 130

EVALUATION...... 140

RELATED WORK ...... 144

CHAPTER 5 - CONCLUSION ...... 148

RECOMMENDATIONS FOR FUTURE WORK ...... 150

REFERENCES ...... 151

vii

LIST OF FIGURES

Figure 1 - Economics of Product Lines ...... 13

Figure 2 - Feature Diagram Notations ...... 21

Figure 3 – FODA Feature diagram ...... 23

Figure 4 – MDA Model Transformation ...... 30

Figure 5 – MDA Mappings Diagram ...... 32

Figure 6 - SOA with Request-Response message...... 36

Figure 7 - Web Services Architecture stack ...... 54

Figure 8 - SOA Envelope ...... 57

Figure 9 - WS-BPEL layered standards ...... 62

Figure 10 - BPM lifecycle ...... 64

Figure 11 - BPD Core Elements ...... 67

Figure 12 – Business Process Diagram ...... 68

Figure 13 - Evolution of Semantic Web Services ...... 75

Figure 14 - Top level of OWL-S Service ontology ...... 78

Figure 15 - Ontology diagram ...... 82

Figure 16 - The top-level elements of WSMO ...... 87

Figure 17 – WSMX Architecture ...... 87

Figure 18 - Overview of MDA and Ontology-based Service Modeling...... 102

Figure 19 - Semantic Business Process Management...... 103

Figure 20 - MDA approach to FODA4SWS...... 120

Figure 21 - BPMO Architecture ...... 129 viii

Figure 22 - e-Rx Feature Model (Problem Space Model) ...... 133

Figure 23 – e-Rx BPMN (Solution Space Model Template) ...... 134

Figure 24 - e-Rx Ontology ...... 139

LIST OF TABLES

Table 1 - Conceptual mappings between SoaML and WSMO ...... 50

Table 2 - Mappings between features and business process model template activities .. 135

ix

CHAPTER 1

INTRODUCTION

As information technology (IT) evolves its role in the operations of businesses has also evolved. The role of IT has shifted from enabling the automation of processes to being an integral part of business operations such as in the planning, design, implementation and optimization of business processes. IT evolution has also seen a shift towards distributed software systems which has resulted in demands for better communication, integration and collaboration between entities in the distributed systems. Other factors driving IT evolution are the demands for system architectures to be more flexible and adaptable to changes, and for better alignment of business processes with IT, the latter of which has fuelled a move towards organizational transformations evident in business process re- design or re-engineering, in order to better exploit the capabilities of IT in business operations.

While companies in sectors such as e-banking and e-commerce have exploited this form of transformation to form networks of integrated IT systems, the healthcare domain or e-health continue to experience major challenges in interoperability between applications throughout the healthcare network. One reason for this is that the adoption of technology does not usually occur at the same rate in the different departments in this domain resulting in heterogeneous applications distributed over diverse platforms.

According to Taylor (2006), there has been a history with many examples of promising

1

IT innovations in healthcare that have failed to have the anticipated impact, due in part to the fact that organizational transformation is harder to effect in the healthcare domain by nature of it being such a complex and life impacting domain.

The healthcare domain is faced with demands for accessible, efficient and safe patient care. Incidences of adverse drug events resulting from preventable drug-to-drug and other drug-related interactions have had devastating impact on patients’ safety, and on the quality and cost of healthcare. Adverse drug event (ADE) is defined by Bates,

Boyle, Vander Vliet, Schneider and Leape (1995a), as "an injury resulting from medical intervention related to a drug".

The following are some underlying causes of preventable ADEs (Bates et al.,

1995b; Stephens, Fox, Kukulka & Bellamy, 2008), that could be averted with improved interoperability and integration of healthcare systems:

• Known allergies – a patient has a known or documented allergy to the

drug being prescribed which was not accessed or considered by the

prescriber when ordering the new prescription of the drug

• Pre-existing medical condition – potential contraindications to the

prescribed drug, were not identified prior to ordering drug

• Drug-to-drug interactions – interactions with previously prescribed drugs

or drugs that patient is currently taking

• Ordering errors – these include wrong dose of medication, wrong

medication selected, wrong administration direction given

According to the Agency for Healthcare Research and Quality (AHRQ, 2001) - “ADEs result in more than 770,000 injuries and deaths each year and cost up to $5.6 million per 2

hospital, depending on size”. The AHRQ went on to suggest that ADE injuries and associated costs can be reduced if hospitals make changes to their information systems for preventing and detecting ADEs.

We share the view that improvements in safety can be achieved with the prevention or early detection of ADEs, and we believe that occurrences of ADEs can be reduced through better management of prescribed drugs in relation to a patient’s medical history. This requires exploiting IT in healthcare to achieve efficient and effective communication and collaboration between information systems in the e-health domain.

The first step in our research involved identifying the main characteristics of the healthcare domain in order to determine a suitable framework to represent the domain.

We then sought to identify and align the concepts and technologies that would facilitate improved interoperability, integration and communication, in order to form a feasible solution that could be applied to reducing incidences of ADEs. Based on the nature of the e-health domain, it was also essential that the proposed IT solution be flexible and adaptable to changes in business requirements.

Healthcare presents as a domain with distinct but related entities with function- specific IT systems such as – administration systems; laboratory and radiology information systems; electronic messaging systems; and electronic prescriptions systems, that is, each entity is focused on servicing a specific area of healthcare. As such, the e- health domain can be represented as a software product line (SPL).

SPLs are often used to represent families of related systems (Northrop, 2008;

Cohen & Krut, 2010), such as the healthcare domain. Domain analysis, an SPLE process, is usually performed on SPLs to gain understanding of the problem domain including 3

knowledge of existing applications and user requirements, and to represent the domain knowledge in a format that can be easily understood by all stakeholders. For Kang,

Cohen, Hess, Novak and Peterson (1990), feature-oriented approach to domain analysis represents the characteristics of the domain as distinguishable features or conceptual services in a feature model, from which we can create a set of products that define the domain. Planned reuse is the focus of SPL development with benefits such as reduced development cost and improved quality.

Within the e-health domain, each patient is identified by a unique identifier or electronic health record (EHR), which can be accessed and updated by each service providing care to that patient. The different healthcare services offered are usually dispersed across organizational and geographic boundaries, which indicate that e-health also presents as a domain with distributed services and as such, can be structured as a service-oriented architecture (SOA).

SOA is considered to be the most promising paradigm for integrating business processes in a distributed computing environment while providing adaptability through the relative ease of adjusting the available services or the functionalities of these services.

SOA strategy is based on services with services representing specific or choreographed business functionality. Services are self-contained (autonomous), platform-independent, loosely coupled and can be described, published, discovered and orchestrated to form business processes (Juric & Pant, 2008). Business process re-design or re-engineering is a necessary step towards an integrated SOA with Business Process Management

(SOA/BPM) approach that seeks to better align IT with business processes. Web services are the most recognizable realization of SOA that provide the basis for the development 4

and execution of business processes. Web services are designed to support the interoperable interactions of distributed systems over the World Wide Web (Web) using standards such as Web Service Description Language (WSDL), Universal Description,

Discovery, and Integration (UDDI) and SOAP (previously referred to as Simple Object

Access Protocol).

Communication is required in order to integrate e-health systems, to provide complete and consistent patient care. Efficiency in healthcare demands the ability to be able to access and share meaningful and accurate information in a timely manner. This requires that patients’ medical information be securely stored, accessed, managed and shared throughout the healthcare network. Interoperability is an essential component for effective communication between healthcare entities and is required in order for healthcare providers to make informed evidence-based decisions based on available medical information.

WSDL facilitates the exchange of information between Web services, enabling syntactic and functional interoperability (Stroetmann & Stroetmann, 2005) which allows for two or more systems to share information.

While WSDL (Chinnici, Moreau, Ryman & Weerawarana, 2007) describes the interfaces of Web services that facilitate the exchange of information between distributed software systems, it lacks the mechanism to specify the semantics of a Web service.

Semantic Web services is an improvement on Web services which uses Semantic

Annotations for WSDL and XML Schema (SAWSDL) to add semantic annotations to

Web services descriptions to enable semantic interoperability - the ability for information shared by systems to be understood at the level that is processable by computers 5

(Stroetmann & Stroetmann, 2005). SAWSDL defines semantic annotations that are needed to facilitate automatic discovery, composition and integration of Web services

(Farrell & Lausen, 2007).

Ontologies play an essential role in supporting semantic interoperability. As stated by Obrst (2003), “ontologies offer the richest representations of machine- interpretable semantics for systems and databases in the loosely coupled world, thus ensuring greater semantic interoperability and integration”. Semantic interoperability is essential for integrating the concepts that are the focus of this research.

Service Oriented Product Line (SOPL), an integration of SOA and SPL, allows for representing the e-health domain as a family of distributed information systems, in which the domain characteristics or business tasks are exposed as services. Services allow for integrating the business processes of distributed healthcare entities. Semantic

Web services offer great promise for improving the interoperability and integration offered by Web services by enabling business process automation with the use of ontologies.

We advocate a methodology that combines Model driven development (MDD) with ontologies in an integrated SOPL implementation, to address challenges such as interoperability, integration and communication between software systems in a distributed e-health domain.

6

RESEARCH OBJECTIVES and APPROACH

The focus of this research is to define a methodology that can be applied to healthcare for improved interoperability, integration and communication towards reducing incidences of

ADEs. Improved efficiency through business process automation and ready access to constantly changing information, such as Medication Recalls or Safety Alerts systems, are also seen as contributors to ameliorating incidences of ADEs.

This research investigates some emerging technologies and seeks to identify an innovative integration of these technologies. To achieve this objective, we first need to obtain an understanding of certain basic concepts and the relationships between the different concepts before attempting a synergy. Below are the main concepts and technologies investigated further in this research:

• Software Product Line (SPL) Engineering; Domain Analysis, Feature models

• Service Oriented Architecture (SOA); Web Services; Service Modeling

• Business Process Management (BPM); Business Process Modeling

• The Semantic Web; Semantic Web Services

• Model-Driven Development (MDD); Model-Driven Architecture (MDA)

• Ontologies; Ontology Definition Metamodel (ODM)

• Integration – explore the relationship between the concepts – SPL, SOA, BPM,

MDD and Ontologies

• E-Health as a problem domain

7

ORGANIZATION OF ESSAY

Chapter 2 is a literature review of the relevant knowledge areas, which form the theoretical framework for the research. We also discuss the e-health problem domain that will be used to illustrate the proposed methodology in subsequent chapters. Chapter 3 provides the description of the methodology and a discussion on tool support. Chapter 4 presents a case study, evaluation of methodology and a discussion of related work.

Chapter 5 provides a conclusion and recommendations for future work.

8

CHAPTER 2

LITERATURE REVIEW

In this chapter, we will conduct an extensive literature review on SPLs and some other emerging technologies.

We will start by looking at the two major SPL processes – Domain Engineering and Application Engineering, and SPL focuses - problem space and solution space. We will focus our discussion on Domain Analysis, the first phase in Domain Engineering, and on Feature-Oriented Domain Analysis where feature models are used to represent the characteristics of a domain or problem space. We will look at SOA – principles, benefits and issues; Web services as the most mature realization of SOA; and Business Process

Management. We will also look at Ontologies, the Semantic Web and Model Driven

Development (MDD). Semantic Web services offer the promise of automating business process tasks and improving interoperability. MDD is discussed as a feasible software development paradigm to help improve the SPLE process with transformation between models. For each technology reviewed we will briefly discuss the contribution to the problem space or solution space of an SPL implementation. Finally, we will look at electronic health (e-health) as the problem domain and the specific problem of interoperability within e-health which is the focus of this research.

9

SOFTWARE PRODUCT LINE (SPL)

As IT evolves and become more integrated with business operations, there is increasing demand for a software engineering approach that offers quicker time to market (TTM), higher quality, lower development and maintenance costs and improved business agility and flexibility. SPL – a product line approach to software development provides the answers to most of these demands.

Pohl, Böckle and van der Linden (2005) stated “Software Product Line

Engineering (SPLE) has proven to be the methodology for developing a diversity of software products and software-intensive systems at lower costs, in shorter time, and with higher quality.” The focus of SPLE is strategic reuse, which takes advantage of the fact that most organizations produce families of similar systems, differentiated by features.

The Software Engineering Institute (SEI) 1 defines SPL as “a set of software- intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way” (SEI/CMU, n.d.-2).

From the SEI’s perspective, there are three essential product line activities that blend technology and business practices, namely: Core Asset Development, Product

Development and Management (Northrop, 2002; SEI/CMU, 2009). The Core Asset

Development activity is responsible for establishing the production capability for products with three outputs – the core asset base: reusable artefacts and resources that

1 http://www.sei.cmu.edu/productlines/

10

form the basis for the software product line; the product line scope: gives description of products that will be in the product line; and the production plan: which prescribes how the products are produced from the core assets. The Product Development activity depends on the three outputs from Core Asset Development and the product description

(requirements specification) for each individual product. These items are used as inputs to produce products that meet their respective requirements. Management plays a critical role in the success of a product line. Activities must be given resources and then be coordinated and supervised. Management at both the technical (or project) and organizational levels must be strongly committed to the software product line effort

(Northrop, 2002; SEI/CMU, 2009).

As indicated above, core assets form the basis for SPLs. Core assets include the software architecture, requirements specifications, reusable software components, domain models, performance models, test plans, test cases and process descriptions. The architecture is considered to be a key core asset (Northrop, 2002; SEI/CMU, 2009). In the

SEI opinion, the core asset base includes the software development artefacts that are most costly to develop from scratch.

Planning is essential in SPL in order to provide managed reuse, that is, for determining the ways in which artefacts will be reused across the product line. The artefacts may be built from scratch, derived from legacy systems or other reusable artefacts. The artefacts need to be built with flexibility that enables adaptability and reuse in different applications, thereby facilitating mass customisation. Each software application in the product line is a product or customization that is created from the (core)

11

reusable artefacts tailored to meet business requirements, using variations in the pre- defined production plan.

SPLE differs from traditional software engineering in identifying commonalities and managing variability. SPLs are built on the concept of reuse and achieve flexibility by managing variability to create variant reusable artefacts. SPLE system development involves two phases – Domain Engineering (also called Core Asset Development) and

Application Engineering (also called Product Development). Anquetil, Grammel, Galvão et al. (2008) in analyzing the basic concepts of SPLs found that in addition to the Domain

Engineering and Application Engineering processes, SPL paradigm has two main focuses: a problem space which focuses on defining what problem the family of applications will address and a solution space which focuses on producing the software components to solve that problem.

Core Asset Development represents the activity where the basis of SPL is carried out. Product Development is responsible for deriving individual applications from the requirements and composing applications from the family architecture and the software artefacts. ‘Platform’ is used synonymously with ‘core asset set’ in SPL literature. SPL architecture is critical to the success of the product line and if inaccurate, it represents the hardest and most costly component to change. As stated by Batory (1998), "a product- line architecture (PLA) is a blue-print for creating families of related applications".

Batory (1998) went on to suggest that “PLA is a solution to the growing complexity of software which has caused increases in the costs of software development and maintenance”, and also that “PLAs enable companies to amortize the effort of software design and development over multiple products, thereby substantially reducing costs.” 12

Key to SPL success is the architecture, which needs to be structured to enable the organization to respond quickly to changes in the marketplace.

There is significant support for the adoption of SPLE (SEI/CMU, n.d.-2) approach in the development of software systems, especially in domains where the complexity and number of business processes challenges the feasibility and capabilities of traditional software engineering approaches. SPL approach requires significant upfront investment to create the core asset base before the benefits of reduced (overall) cost per product can be realized. The upfront cost associated with SPL is higher than the cost for single system development in traditional single systems approach (shown as ‘Current Practice’ in the graph below). From a cost perspective, SPL is shown to be more beneficial in larger families of systems than in smaller ones since the overall cost of development decreases as the number of products increases, due to the use of reusable artefacts (Northrop, 2008).

In Figure 1, the line with the greater gradient and with starting coordinates (x, y) = (0, 0), represents single system (Current Practice) development approach. The blue shaded area in the upper right of the graph represents savings from an SPL approach as opposed to single systems development approach. Similar to what is seen with cost, the initial TTM for reusable artefacts in SPL, is greater than for single system development. However, the use of reusable artefacts results in an overall shorter TTM for SPL.

Figure 1 - Economics of Product Lines (adopted from Northrop, 2008) 13

Quality assurance can present a challenge for SPLs, which are inherently more complex than single system developments. An error in a core asset, if not caught and corrected early, will get propagated throughout the product line with devastating results. On the other hand, the repeated use of core assets increases the probability of discovering errors, resulting in increased quality as reusable artefacts are repeatedly tested in different products in the product line. Benefits such as decreased TTM, decreased development and maintenance costs, translate to reduced overall cost and increased profitability for enterprises that use SPL to transform their business operations.

The SPL strategy can be summarized in two major development processes (Pohl et al., 2005; Northrop, 2002) – first: Domain Engineering or Core Asset Development identifies the commonalities and variability of the product line that need to be modeled and developed as core and reusable software artefacts. Second: Application Engineering or Product Development. Application Engineering manages the variability for mass customizations and is the process responsible for actual or concrete application development from the reusable artefacts developed during the Domain Engineering process. These two processes have complete development cycles consisting of – analysis or requirements engineering, design and implementation, which are performed in parallel.

As stated by Czarnecki (2004), “Both processes feed on each other: domain engineering supplies application engineering with the reusable assets, whereas application engineering feeds back new requirements to domain engineering. This is so because application engineers identify the requirements for each given system to be built and may be faced with requirements that are not covered by the existing reusable assets. However, the new requirements should be fed back into domain engineering in order to keep the 14

reusable assets in sync with the product needs”. The focus of this paper is on Domain

Engineering, which is discussed in more detail next.

Domain Engineering. Domain engineering is a software reuse approach that focuses on a particular application domain (and in which) we perform domain analysis and capture domain knowledge in the form of reusable software assets (Wang,

Li, Sun, Zhang & Pan, 2005). As defined by Northrop (2002), “a domain is a specialized body of knowledge, an area of expertise, or a collection of related functionality”.

Requirements engineering is conducted to gather product constraints and understanding of domain is sought from pre-existing assets such as legacy systems or domain experts. A product line’s core asset base or reusable artefacts are derived from identifying the architecture and the software components for the architecture. According to Pohl et al.

(2005) “components of a reusable platform include software artefacts such as requirements, design and realisation”, and “platforms are used to produce variants based on planned reuse”.

As per Alana and Rodriguez (2007) in GMV Domain Engineering Methodologies

Survey - the Domain Engineering process is divided into three main phases - Domain

Analysis, Domain Design and Implementation. The Domain Analysis phase is responsible for discovering and modeling the commonalities and variability of a domain that are used to build reusable components; the Domain Design phase defines the reference architecture or framework for the development of reusable components and Domain

Implementation is the phase responsible for the actual development of the reusable components. The focus of this report is on Domain Analysis which is discussed next.

15

Domain Analysis. Domain Analysis is defined by Kang et al.

(1990) as “the process of identifying, collecting, organizing, and representing the relevant information in a domain based on the study of existing systems and their development histories, knowledge captured from domain experts, underlying theory, and emerging technology within the domain”. Domain analysis captures the domain knowledge, offers the ability to identify the features of systems in the domain and support development of reusable software components. Reuse results in improvement in the software development process as it enables new products to be developed in a shorter time and at a lower cost. However, success with reuse is dependent on accurate and complete identification of the features, relationships and capabilities of related systems in a problem domain.

To achieve success at developing large and complex systems with reusable components, the domain analyst needs to determine methods for finding domain information in order to obtain a thorough understanding of the domain, the desired system features and the capabilities of the software required to implement those features.

These methods usually include harnessing the experience and knowledge of domain experts as well as pre-existing legacy systems. As such, domain analysis involves a systematic exploration of the domain to capture the basic features, relationships between features, known problems and solutions, and to organize this information in ways that can be easily communicated and understood by stakeholders and reused in software products in the domain.

Kang et al. (1990) underscores the importance of Domain Analysis in the following statement: “the availability of domain analysis technology is a factor that can 16

improve the software development process and promote software reuse by providing a means of communication and a common understanding of the domain”. Domain models are outputs of the domain analysis process which are used to describe the elements of systems (in a given application domain) from the point of view of a "problem space", that is, what the systems in that domain must do. It complements the architecture model (the solution space), which describes various ways in which systems may be built to meet the requirements of the domain model and the operating environment. Domain models include: entity-relationship model, feature model, functional model and domain terminology dictionary. Domain terminology dictionary is a key but often overlooked domain model that is used to standardize the terminology that describes the domain

(Kang et al., 1990).

There are many approaches to domain analysis. Alana et al. (2007) discussed three classifications of methods used for domain analysis – first: based on Product Line

Processes; second: based on domain engineering and object oriented analysis and design

(OOA/D) and third: based on the goal of analyzing and modeling the domain to achieve reuse. The current trend is towards increasing reuse in software development towards achieving benefits such reduced development costs, improved quality and shorter time to market. For these reasons the third domain analysis approach will be the focus of this research. As stated by Alana et al (2007), examples of the third approach include:

Feature-Oriented Domain Analysis (FODA), Feature Oriented Reuse Method (FORM) and Feature Reuse-Driven Software Engineering Business (FeatuRSEB). Both FORM and FeatuRSEB are extensions of the FODA methodology. The domain analysis

17

approach focused on in this research is the FODA methodology developed at the

Software Engineering Institute (SEI).

Feature-Oriented Domain Analysis (FODA). FODA is a method for performing domain analysis. According to Kang et al. (1990) – “The primary focus of

FODA is the identification of prominent or distinctive features of software systems in a domain and a primary goal is to make domain products reusable. These features are user- visible aspects or characteristics of the domain, that is, those features a user commonly expects in a domain. Features define both common aspects of the domain as well as differences between related systems in the domain. The features lead to the creation of a set of products that define the domain and also give the method its name”. The FODA focus is to identify factors that can cause differences among applications in a domain at the functional and architectural level and use those to parameterize domain products.

Customizations or specific applications in the domain are developed as refinements of the domain products.

FODA focuses on identifying the commonalities and variability in the domain in terms of mandatory, alternative or optional features of the related systems in the domain.

The domain analysis process in FODA is divided into three phases – Context Analysis,

Domain Modeling and Architecture Modeling. In Context Analysis, the scope or boundaries of the domain are defined with the help of domain knowledge experts.

Domain Modeling performs three processes to identify the commonalities and variability of the domain, namely: Feature Analysis, Entity-Relationship (ER) modeling and

Functional Analysis. The results from the three processes are models that describe

18

different aspects of the problem space, namely, Feature Model, ER Model and Data Flow

Model respectively.

The Standish Group, in their 1994 CHAOS Report brought focus to some reasons for failures and successes in software projects (Standish, 1994). According to this report, the main reasons for software project failures are issues caused by poor or inappropriate software analysis. The three main reasons cited for software success are: user involvement, executive management support, and a clear statement of requirements, while the main reasons for challenged and failed software projects are the lack of user input, incomplete requirements and specifications, and changing requirements or specifications. These reasons underscore the need for mutual understanding between requirement engineers, end-users and domain experts, the importance of the accuracy of requirement specification and the significance of the different levels of analysis such as feature analysis and functional analysis.

Identifying and understanding factors that result in different applications or different implementations of similar applications in a domain is the basis for parameterization. Applications in a domain provide a large set of common capabilities and sets of variant capabilities, which make each application different from others. These capabilities from the perspective of end-users are modeled as ‘features’. The feature analysis process involves: collecting source documents, identifying features, abstracting and classifying the identified features as a model and validating the model. As stated by

Kang et al. (1990), “the feature analysis process focuses on capturing, in a model, the functionality of applications, that is, the ‘services’ provided by the applications, from an end-user perspective of the general capabilities of applications in a domain”. Feature 19

Analysis is the first formal analysis activity performed on the domain. The resulting variability feature model is used in subsequent processes such as in functional analysis and in modeling the architecture or solution space.

In FODA, Architecture Modeling focuses on providing an architectural model or software "solution" to the problems defined in the domain modeling phase. A primary goal of the FODA method is to make domain products reusable. In the development of an architecture model, architecture layering is done so that reuse can occur at the layer appropriate for a given application and the impact of technical and requirements changes to the model can be localized. An architecture model must address the problems defined in the domain in a way that the model can be adapted to future changes in the problems and technology. This adaptation is achieved through architecture layering. A FODA architecture model is a high-level design of the applications in a domain. Therefore, the

FODA method focuses on identifying concurrent processes and domain-oriented common modules, and on allocating the features, functions, and data objects defined in the domain model to the processes and modules (Kang et al., 1990). In a typical development, the domain analysis process would be iterative and would rely on users’ and domain experts’ feedbacks to verify the model outputs produced by the process.

The completeness and accuracy of the feature model, in terms of the identified features and their relationships, have a significant impact on the effectiveness and success of the FODA methodology in defining a domain. An error in the feature model, if not caught and corrected early, will be propagated throughout the system. This places great importance on the feature analysis process to ensure that the resulting feature model

20

accurately represents the domain. For these reasons the feature model, a product of the

Domain Analysis process, is the focus of this paper.

Feature Model. A feature model represents the standard features of a family of systems in the domain and the relationships between them (Kang et al., 1990). Unique combinations of features are used to distinguish between members or products of a product line. Kang et al. (1990) describes features as “the attributes of a system that directly affect end-users.” The end-users make decisions regarding the availability of features in the system, and they have to understand the meaning of the features in order to use the system. For Czarnecki, Antkiewicz, Kim, Lau and Pietroszek

(2005), “features are prominent functional and/or non-functional characteristics of the systems”. The authors also offered the following descriptions for feature models: requirements-level artefacts useful for scoping product lines; provides a vocabulary that concisely describe members of a product line; can be used to create feature configurations as input to an automated product derivation process.

Feature models are usually represented as a feature diagram, which is a hierarchical construct or a tree-like representation of the relationships between a parent feature and its child features (sub-features). Five primary relationships are: mandatory; optional; and; alternative; and or. Figure 2 shows the graphical notations that are most often used to represent these five relationships in feature models.

Figure 2 - Feature Diagram Notations 21

And – Two or more child features are connected to the parent feature, all ‘and’ sub features must be selected in a configuration

Alternative – Two or more child features are connected to the parent feature with an arc connecting the alternative sub-features. Only one ‘alternative’ sub-feature can be selected. We will see later that the presence of a cardinality allows for the selection of more than one alternative features.

Or – Two or more child features are connected to the parent feature. One or more ‘or’ sub-features can be selected.

Mandatory – Mandatory sub-features are connected to their parent feature by lines with a solid circle at the child end. These sub-features are seen as required or common, that is, they are found in all software products in the product line. (NB. The feature model diagrams in Kang et al. (1990) use a connector line without a solid circle at the child end to represent this relationship.)

Optional – Optional features are connected by way of a line with an un-shaded circle at the child end.

In addition to the five described relationships, there are composition rules and constraints that define the semantics existing between features or how features relate to each other, which are not expressed in the feature diagram:

Mutually exclusive with (A) – means selecting A excludes other features associated with

A from being selected

Requires - indicates a dependency between features, one feature requires another

22

A feature diagram provides a graphical tree-like notation that shows the hierarchical organization of features in a view that is easy to understand. The features are representative of the ‘services’ that will be provided to the users. The root feature or node denotes the SPL being modeled. Each child feature (sub-feature) is connected to exactly one parent feature. In Figure 3, there is an example of a feature diagram, which depicts the standard features of a Motor Engine system.

Figure 3 – FODA Feature diagram (adopted from - Bontemps & Heymans, 1990)

A feature model gives information about the features to be formed into products or valid composition of features known as configurations. The features in a feature model are used to distinguish products in the product line and as such each product is composed of a unique combination of features. A valid product or configuration is one that meets all type restrictions, constraints and dependencies depicted in a feature model (Zaid,

Cimpian, Mazzara & Zaremba, 2009).

Griss, Favaro and d’Alessandro (1998) integrated FODA-based feature model with use-case driven Reuse-Driven Software Engineering Business (RSEB) to form

FeatuRSEB, which uses separation of duties between use case modeling and feature modeling roles to simplify the feature modeling process. Czarnecki, Kim and Kalleberg

23

(2006) suggests that as conceptual models, both feature models and ontologies have similar roles in providing information such as variability that is used in modeling a domain, and that a semantic configuration of a feature model represents the set of restrictions or constraints that can be applied to an ontology, which led to their proposal that ‘feature models are views on ontologies’. The need for tool support that utilizes query and constraint mechanism was also highlighted in their research.

While feature models are widely accepted as a tool for capturing and representing commonalities and variability in a domain, the consensus from a number of research

(Wang et al., 2005; Zaid et al., 2009; and Mohabbati, Kaviani & Gaševi, 2009), is that there are some challenges with feature models, such as: lack of a formal semantics and not being expressive enough to effectively represent the relationships and dependencies between the features in a domain. The direction of current research is towards incorporating ontologies in feature model to resolve these noted issues. According to

Johansen, Fleurey, Acher, Collet and Lahire (2010), “ontology modeling can improve feature modeling by providing additional information relevant for the domain in which a feature model is constructed. Finding synergies between feature models and ontologies will aid an SPL engineer in accurately expressing, organizing and representing features in their feature models”. We will look further at the integration of ontologies in feature models later in this chapter.

SPL Contribution. In this section we saw that SPLE involves two major processes – Domain Engineering and Application Engineering. We focused on Domain

Engineering, which includes Domain Analysis - the phase responsible for gaining understanding of the domain or problem space, gathering requirements, modeling and 24

representing the problems of the domain in an understandable form, usually a feature model. We mentioned different types of domain analysis with a focus on FODA, which uses a feature model to represent the commonalities and variability of a domain or problem space. Since feature models are used to define the domain, including the relationships and constraints between the domain features or user-visible services, they can therefore be seen as representations of the problem space. By extension, Domain

Engineering and (Feature-Oriented) Domain Analysis contribute to defining the product line’s problem space.

SOFTWARE DEVELOPMENT

MDD is a software development approach that uses models to add abstraction and provide an environment for rapid product derivation. Application Engineering is the SPL process where product derivation occurs, that is, the constructing of concrete products from the core assets base defined during Domain Engineering. This section looks at

MDD as a software development approach and discusses its contribution to an SPL implementation.

MODEL DRIVEN DEVELOPMENT (MDD). Model Driven Engineering (MDE) was defined by Bézivin, 2005 (as cited in Gaševi, Kaviani & Milanovic, 2009a), as “a new software engineering discipline in which the process heavily relies on the use of models”. According to Gaševi et al. (2009a), the software engineering community puts a lot of attention to the MDE discipline to enable model-driven development of software products. The authors also stated that model transformations such as model-to-model, 25

model-to-text and text-to-model, are the key concepts of MDD which allow for round trip engineering (i.e., forward and reverse engineering) of software products. Another definition of MDE offered by Asadi, Mohabbati, Kaviani, Gaševi, Boškovi and Hatala

(2009) is that “MDE is a software engineering approach in software development which moves the focus of software development from implementation to the problem domain by raising the abstraction in software artefacts development and automating implementation with means of transformation”. From these definitions we can deduce that - an MDD approach to software development involves the extensive use of models to represent different aspects of target system; MDE is a software engineering methodology which uses models to add abstraction away from the software artefacts being developed; and also that MDD falls under the umbrella of MDE. Raising the level of abstraction is a key feature to advancing progress in software development. Moving to higher levels of abstraction yields many benefits, including higher productivity, fewer defects, and easier maintenance and enhancement. This, according to Regio, Greenfield and Thuman (2005), is the goal of MDD.

Model driven architecture (MDA) is the Object Management Group’s (OMG’s) vision towards an MDD approach to domain development that would help to reduce complexity, lower costs, and hasten the introduction of new software applications. MDA provides a framework to MDD. According to Miller and Mukerji (2003) – “the basic function of MDA is the generation of applications from a set of procedures (UML mode).

This generation is independent of the platform and language used”. MDA is an approach to software development that produces and maintains computer industry specifications for interoperable enterprise applications. The goal of MDA is one that is often sought: to 26

separate business and application logic from its underlying execution platform technology so that changes in the underlying platform do not affect existing applications and business logic can evolve independently from the underlying technology (Lewis &

Wrage, 2005).

Four principles underlie the OMG's view of MDA (Brown, 2004):

• Models expressed in a well-defined notation are a cornerstone to understanding

systems for enterprise-scale solutions

• The building of systems can be organized around a set of models by imposing a

series of transformations between models, organized into an architectural

framework of layers and transformations

• A formal underpinning for describing models in a set of meta-models facilitates

meaningful integration and transformation among models, and is the basis for

automation through tools.

• Acceptance and broad adoption of this model-based approach requires industry

standards to provide openness to consumers, and foster competition among

vendors.

MDA is a way to organize and manage enterprise architectures supported by automated tools and services for both defining the models and facilitating transformations between different model types (Brown, 2004). MDA defines three viewpoints (levels of abstraction) for analyzing systems. Given a viewpoint, we can define a representation of a system under study, that is to say, “a model of the system seen from that viewpoint”

(Gaševi, Djuri & Devedži, 2009b). The models corresponding to the viewpoints are

27

computational-independent model (CIM), platform-independent model (PIM), platform- specific model (PSM). In an MDA specification of a system, CIM requirements should be traceable to the PIM and PSM constructs that implement them, and vice versa.

The following are insights into the three viewpoints (Gaševi et al., 2009b; Miller &

Mukerji, 2003):

• A CIM is sometimes called a domain model and a vocabulary that is familiar to

the practitioners of the domain or domain experts. The CIM does not show

details of the structure of the system. In software engineering, it is well known as

a domain model specified by domain experts, which is very similar to the concept

of an ontology.

• A PIM is a view of a system from the platform independent viewpoint. A PIM

exhibits a specified degree of platform independence so as to be suitable for use

with a number of different platforms of similar type. The PIM is a computation-

dependent model, but it does not consider the characteristics of specific computer

platforms. In other words, the PIM is a model assumed to be executed on a

technologically independent virtual machine.

• A PSM is a view of a system from the platform specific viewpoint. A PSM

combines the specifications in the PIM with the details that specify how that

system uses a particular type of platform. The PSM finalizes the specification of

a whole computer system. The main goal is to shift developers’ focus from the

PSM to both the PIM and the CIM. In this way, platform-specific details should

be generated using various tools for automatic generation of those details (e.g.,

code). 28

Model transformation which is the process of converting one model to another model of the same system (Miller & Mukerji, 2003) plays a key role in MDA. Models are first- class artefacts integrated into the development process through the chain of transformations from PIM through PSM to coded application. The Meta-Object Facility

(MOF) technology provides a model repository that can be used to specify and manipulate models, thus encouraging consistency in manipulating models in all phases of

MDA and ensures that models can be rendered into XMI for transport over a network.

XMI defines an XML-based interchange format for UML and other MOF-based metamodels and models. (Miller & Mukerji, 2003; OMG, 2010).

Model Transformation Definition. The following model transformation definition was adopted from Bézivin, Gérard, Muller and Rioux (2003):

Consider a transformation t that transforms a model Ma into another model Mb as defined by:

t: Ma -> Mb where Ma is based on (conforms to) meta-model MMa and similarly

Mb conforms to MMb, which are represented as sem(Ma, MMa) and sem(Mb,

MMb) respectively. The transformation t is also a model and can be represented

as transformation model Mt such that Mt: Ma -> Mb with similar rules for Mt;

(Mt, MMt), which indicates that Mt conforms to a transformation meta-model

MMt. This rule would apply to any MOF based MDA meta-model; sem(Mt,

MMt), sem(MMt, MOF) and sem(MOF, MOF).

Based on these rules a model transformation operation can be represented by the following relation (Bézivin et al., 2003): Mb  (MMa, MMb, Mt, Ma)

29

This means that a target model Mb which conforms to meta-model MMb is obtained from source model Ma (which conforms to meta-model MMa) by applying Mt: transformation rule based on a standard transformation language.

Figure 4 gives a diagrammatic representation of a model transformation with relations between models:

Figure 4 – MDA Model Transformation (adopted from Gaševi et al., 2009b)

Atlas Transformation Language (ATL), an Eclipse Plug-in, is often used to perform model-to-model transformations (Jouault, Allilaire, Bézivin, & Kurtev, 2008). ATL provides a way to produce a number of target models from a set of source models. An

ATL transformation program is composed of rules that define how source model elements are matched and navigated to create and initialize the elements of the target models. ATL aims at providing a set of transformation tools that include a transformation repository, sample transformations and an ATL transformation engine (ATL, n.d.).

30

Modeling, MDE, MDD and MDA have been the focus of significant research.

Anquetil et al. (2008) sees MDD as a natural candidate to fit in the general framework of

SPL and described how MDD could be applied to SPL with the definition of meta- models for the problem and solution spaces and rules to perform the transformations.

With MDD, models are developed at different abstraction levels or development stages and there is a need for these models to be in-sync to maintain consistency and ensure that changes made at one level reflects in the other levels. This "round trip engineering"

(Gaševi et al., 2009a), is potentially more challenging in the inherently more complex

SPLs than in traditional software development. Traceability provides the answer to this challenge. According to Anquetil et al. (2008), "traceability means to link several artefacts at different levels and the rationale of this link." The authors highlighted the importance of traceability in SPLs and consider traceability to be a fundamental modern software development discipline which presents more of a challenge in SPLs due to factors such as: the large number and heterogeneity of documents than in traditional software development; the need to have a basic understanding of the variability consequences during the different development phases; and the need to establish relationships between product line members and the product line architecture.

Bayer and Widen (2001) suggests that adding semantics to traceability enhances its usefulness beyond just bi-directional links.The authors’ proposed traceability mechanism (for product lines), satisfy the following requirements – it should be based on the semantics of models used in the product line infrastructure; it should be customized to capture relevant trace types; it should be capable to handle variability; the number of traces should be as small as possible; and it should be automatable. 31

In addition to identifying the connection between feature models and ontologies,

Czarnecki et al. (2006) also proposed that syntactic correspondence between a feature model and an ontology establishes traceability links between feature model and ontology elements, such that feature elements (features and relationships) may be mapped to ontology elements (classes and associations). This association suggests that ontologies can be integrated with MDD to elicit traceability between models at different abstraction levels. Raghupathi and Umar (2008) explored an MDA approach to solve issues such as interoperability, portability and scalability that exist in health care information systems.

Model to model (M2M) transformations were performed using MDA, for example, a PIM

(class diagram) was transformed to a relational PSM. The separation of the PIM from the

PSM enables the incorporation of open standards, leading to interoperability, while achieving portability and minimizing vendor lock-in. Figure 5 shows the authors’ proposed three-tiered architecture of a health clinic system which is comprised of a database, Enterprise Java Beans (EJBs) as the middle tier and with the User Interface built in Java Server Pages (Raghupathi & Umar, 2008):

Figure 5 – MDA Mappings Diagram (Raghupathi & Umar, 2008) 32

MDD Contribution. A model driven approach speaks of benefits such as reuse, reduced cost, shorter development time and automation. MDA by OMG is built on the concepts of models and transformations and inherits the benefits associated with

MDD. MDA is seen as a natural fit for SPL applications. Defining all aspects of a system as models is viewed by some researchers as a disadvantage when compared to other approaches, in particular Software Factories (Regio et al., 2005, which uses a combination of model driven development, component-based development, and agile development methods.

Integrating MDE techniques with SPLE allows for incorporating MDD in the management of product line derivations which will see models used in the entire SPLE development process from representing the problem space and the solution space to be used in the mapping or transformation between models and in product derivation. Once problem space models are constructed they can be mapped to solution space models or be transformed into more refined models. An integrated SPL/MDD promises to accelerate the product development process with the potential for significant productivity gains and increased efficiency over traditional development approaches.

SERVICE-ORIENTED ARCHITECTURE (SOA)

The paradigm shift towards service-oriented computing (SOC) for distributed computing has seen the use of services as the basic building block for distributed applications. SOC is built on composition and reuse of existing services across heterogeneous platforms

(Papazoglou, Traverso, Dustdar & Leymann, 2007). This raises the question - ‘What is a 33

service?’ A service in the context of SOC is a loosely coupled reusable software system component that is platform independent, protocol independent and self-contained

(Papazoglou et al., 2007).

A service is not necessarily linked to a business process, as any component which demonstrates reusable functionality in varying applications can be a candidate for a service (Sanders, Hamilton & MacDonald, 2008). However, the vast majority of services either in whole or in part, can be mapped to some business process. A service provides a specific function or capability, which can be either a single discrete function or a composition of a set of related business functions. According to Ort (2005), services that perform a related set of business functions, as opposed to a single function, are said to be

"coarse grained".

An essential component for the operation of SOC is its architectural framework - service-oriented architectural framework. SOA is essentially a collection of reusable platform-independent services, which can be integrated or composed into distributed applications. Nickul, Reitman, Ward and Wilber (2007) sees SOA as a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains and implemented using various technology stacks. Wahli, Burroughs,

Cline, Go and Tung, (2006) describes an SOA as consisting of three essential components – a service provider, a service requester and a service registry (or service broker). The service provider creates services and publishes its interface and description to the registry. The service requester (consumer) uses find operations to query the registry for a service and then binds to the service provider (of the service it found) to invoke a service. The service registry is like a directory of available services, which is 34

responsible for making the service description and interface accessible to consumers

(Wahli et al., 2006). For SOA and Web services, the consumer and service interactions and the requisite responsibilities are defined by the service interface and, more specifically, by a set of service interface artefacts. Multiple services can be used together in a coordinated way forming a composite service. Composite services can be used to satisfy more complex business requirements.

Gaševi and Hatala (2010) share the view that SOA facilitates among other things, increased agility in the development and maintenance of processes, to better respond to newly emerged or changing requirement. As stated by Erl (2006), “SOA is based on the concept that solution logic is partitioned into multiple units of logic that can be assembled to collectively automate business tasks.” SOA paradigm enables the creation of new services or capabilities, discovery of existing and the integration of combinations of services (new and existing). SOA facilitates better collaboration and communication through the exchange of messages and the building of applications from the composition of available services on a network.

Messaging represents the method of interactions and communications between service consumers and providers. A message contains information such as requests or instructions on how to access service that is required to facilitate the interaction. As stated by Bean (2009), “the movement of messages between consumers and services follows a set of patterns known as Message Exchange Pattern or MEP. The most common pattern is known as the request-response pattern. The requester (usually a service consumer) sends a message to the service and a response message is returned to the consumer”. In a basic request-response message exchange, the request message 35

contains the instructions and content that the service requires in order to understand and then execute against the request. The reply message contains response content, an acknowledgement of success, or an acknowledgement of failure.

Figure 6 below shows a basic SOA during a simple request-response message exchange between service consumer (requester) and service provider.

Figure 6 - SOA with Request-Response message (Nickul et al., 2007 - modified)

According to Parastatidis, Watson & Webber (2005) “ the underlying transport protocol for transferring messages may vary from application to application and may differ between different message exchanges within the same application.” Messaging plays a critical role in SOA in facilitating interactions between consumers and services. Later we will see the role of messaging in some core SOA principles.

Core SOA Principles. SOA principles are used in the design and development of services as well as to define the framework in which service consumers and service providers will collaborate. Erl (2006) identified eight common SOA principles, four of which were identified as core principles, namely: autonomy, loose coupling, abstraction and the need for a formal contract, that form a baseline foundation

36

for SOA and which directly enable the realization of the remaining four principles: reusability, statelessness, discoverability and composability. Bean (2009) identified loose coupling, reusability, interoperability, discoverability and governance as being core SOA principles. The (eight) combined core principles from these two references are described below:

• Service Contract. Service contract is viewed by Erl (2006) as one of the eight core

SOA principles. According to Erl, “services are formally defined using service

description documents which, for web services, are typically the Web Services

Description Language (WSDL) definition and the XSD Schema, which contains

descriptions of the service interface including the operation a service provides.

Service description documents establish a service contract which is a set of terms

and conditions specified by the service provider, which must be met and accepted

by the service consumer in order for the two to communicate”. Loosely coupled

services in an SOA require the information in service contracts in order to

communicate, and towards achieving reusable, interoperable and agile

applications. According to Bean (2009), “the WSDL describes a service as a

combination of type references, ports, operations, and bindings. When combined

with XML Schemas for the types, the WSDL can be thought of as the overall

service interface and contract”.

• Autonomy. Service autonomy provides an execution environment conducive to

reusability. A high level of autonomy means a service can exist as a standalone

building block with significant control over the underlying resources. This

enables the service to provide more reliable and predictable performance. A 37

service with increased control over its own execution environment reduces the

dependencies on shared resources within the enterprise (Erl, 2006).

• Abstraction. With abstraction, services are established as ‘black boxes’ with the

underlying logic hidden from potential service consumers. A service may be

designed to perform a simple task, to expose logic from multiple different

underlying systems or as a wrapper to expose the functionalities of legacy

systems. As is the case with Web services, services can abstract the proprietary

implementation details of the underlying automation logic, which frees potential

consumers of the service from having to interface with specific vendor

technologies. Abstraction is accomplished through the design and use of service

contracts. The more that is expressed in the service contract, the less detail is

abstracted. Therefore, the more generic service contract, the less specific the

service will be (Erl, 2006).

• Loose coupling. Loose coupling is a principle that functions to protect the

individual integrity of each SOA consumer and service and to avoid physical

dependencies between the two. Loose coupling helps to mitigate the impact of

service changes to consumers. To comply with the loose coupling principle,

consumers and services do not communicate directly but do so through message

exchange (Erl, 2006; Bean, 2009).

• Interoperability. Like loose coupling, interoperability is critical to implementing a

successful SOA. Interoperability is a principle that eliminates technology

specificity and constraints that may prohibit, restrict, or constrain the ability to

collaborate in the SOA. Interoperability allows consumers and services that are 38

developed using different technologies and on different platforms to exchange

information and collaborate. Messaging plays a significant role in supporting the

interoperability principle. Interoperability helps to ensure that services can be

used by consumers of almost any technology (Erl, 2006).

• Reusability. The principle of reusability in SOA is to design and develop service

components with an emphasis on cost avoidance or reduction. To achieve service

reuse there are dependencies on other principles such as loose coupling,

interoperability and the ability to discover a service. A model driven approach to

SOA development simplifies service development; by abstracting away from the

underlying business logics and expediting service development and as such is

considered to be an ideal approach to developing reusable artefacts and reducing

development cost (Bean, 2009). According to Erl (2006), “the primary strategic

goal associated with reuse is to position each service as an IT asset with

‘repeatable value’”. Reusability optimizes the design and development process

and helps to avoid new development costs while improving an organization’s

response time to change and increasing the level of automation.

• Discoverability. Service discovery is an important SOA principle. Before a

service can be reused or consumed it needs to be discovered. The typical solution

to service discovery is a service registry which contains published information

about a service. Discoverability supports reusability and requires that services are

published in a manner that allows them to be easily found (discovered) for later

reuse (Bean, 2009).

39

• Governance. A successful SOA and services implementation will incorporate

services and service artefacts that comply with the loosely coupled, interoperable,

reusable, and discoverable principles. SOA governance will provide the rules and

framework from which compliance to these principles can be measured and iden-

tify opportunities for appropriate remediation of non-compliance. Governance is

pervasive through design and development and is part of the operational

interactions between consumers and services with the ESB (Enterprise Service

Bus). In this regard, SOA governance considers three different views: Design-

time, Bind-time and Run-time (Bean, 2009):

o Design-time governance – This includes a combination of different activities,

and can be expressed as a set of design rules. Several methods exist for

design-time guidance including design patterns and development technology

(such as model driven development), that are used to ensure that services and

service interface artefacts are loosely coupled, reusable, and discoverable and

to determine if an artefact is in compliance with the rules.

o Bind-time governance – This involves the mechanical steps of associating

consuming applications with services. To enable a consuming application to

invoke and interact with a service requires a form of “binding.” The term

binding is the technology reference between the consuming application and

the interface of a service.

o Run-time Governance. This is SOA technology driven and can include a

number of different types. The most common examples of run-time

governance include quality of service (QoS), validation, transformation, 40

security, and endpoint indirection. As a run-time policy, QoS is a target

measure where the availability and performance of a service for its consumers

is monitored and managed. Run-time validation governance ensures that the

structure and content of a message comply with the defined interface for the

service. Run-time transformation governance can apply a message

transformation (converting one message format to another) to ensure that the

target for a message will receive a format it can interpret. Run-time security

governance can help to enforce the authentication and authorization of

consumers for services. The enforcement of run-time governance is most

often enabled by Web Services Management (WSM) technologies and will

also often require a service repository to act as the source for governance

policies (rules for compliance).

In addition to the core principles there are some other requirements for an effective SOA.

Wahli et al. (2006) indicated that in order to efficiently use a SOA, the architecture must meet some key requirements, some of which are discussed below:

• Clear and unambiguous description language – clearly defined platform-

independent syntax for service interface required to access service provider

• Security - Protection of the services and information passed to and received from

the services, against unauthorized and malicious access must be supported by the

platform. Security is required to empower and retain authenticated and authorized

requesters/customers while restricting access to everything and everyone else

41

• Desire to create a federation of resources - establish and maintain data flow to a

federated database system which functions to integrate multiple autonomous

database systems. This allows new functionality developed to reference a

common business format for each data element

SOA Capabilities. While SOA is not specific to any one technology or product, an effective and successful SOA is dependent on the capabilities of a combination of supporting technologies. According to Bean (2009) the supporting technologies include Enterprise Service Bus, Service Registry and Repository, Business

Activity Monitoring, Web Services Management and Business Process Management.

• ESB is a fundamental backbone technology that supports SOA. The bus is a

technology capability that includes the network, transport, routing, delivery of

messages and content, and supporting communication protocols all of which are

intended to be somewhat hidden or transparent to service consumers.

• Service Registry and Repository (SRR). For an SOA with a limited number of

consumers and services that are all well known to the organization, the

collaboration between service consumer and service can work. However, as the

number of consumers and services grows, remembering which service provides

what functionality and the location of the service endpoints to send messages

quickly becomes unreasonable requiring the functionalities of an SRR.

• Business Activity Monitoring (BAM). SOA events include the movement of

messages between SOA participants and collaborators, the successful replies

from services to consumers, and the errors or faults that are raised. Defining

42

measures for each of these activities is critical for monitoring the health of the

SOA as well as for presenting opportunities to optimize service interactions and

avoid problems. BAM is a technology that monitors the SOA infrastructure and

reports on the noted activities as well as others.

• Web Services Management is a technology that works with the ESB to trap

events (usually at endpoints) and to either take action directly or to instruct the

ESB to take action. The emphasis of WSM is on the definition and the

application of what are often described as policies. Policies are sets of behaviour

that can be defined to resolve a number of different activities such as security,

redirection, transformation and validation.

• Business Process Management is discussed later in this chapter.

Enterprise SOA bridges the gap between people, businesses and IT. According to

Casanave (2009); “SOA is about how people, organizations and systems work together to achieve some mutual business goal by providing and using each other’s services”. SOA can be positioned as a technology or business architecture and can be applied at a very high level, to understand an enterprise or community or at a very detailed level to understand and specify a particular service operation offered between systems. This wide scope and the ability to “connect the dots” between business and technology concerns is one of the advantages of SOA and what is called Enterprise SOA (Casanave, 2009).

Benefits and Challenges of SOA. According to Juric and Pant (2008),

SOA introduces technologies and languages that reduce the semantic gap between the business processes (diagrams) and the actual applications (code). The authors also stated 43

that ‘SOA's main motivation is to provide a backbone for an organization's business processes.’ Other benefits of SOA include - reduced cost, shorter TTM, improved flexibility and adaptability in being able to respond more quickly to changes in business needs or the global market environment, which according to Juric and Pant (2008) is facilitated by a process-driven approach to SOA. Benefits directly associated with services being loosely coupled are maintainability and scalability. SOA also allows for the “globalization and the integration of geographically dispersed organizations through service orchestration of distributed services owned and executed across ownership boundaries” (Dandashi & Ang, as cited in Sanders et al., 2008). Studer, Grimm and

Abecker (2007) considers Web Services to be a basic building block in the creation of

SOA with SOA seen as “an architecture that is well suited to map the dynamic environment that enterprises are confronted with in today’s globalized world”. They stated further “in the SOA vision, they (architectures) will no longer be programmed, but instead be ‘composed’ of loosely coupled components which will be imported from servers from all over the world. Required services will be dynamically, potentially during run time, searched and called when needed”.

SOA provides a modular architecture of services that is flexible, adaptable and can be easily integrated into business operations. One significant benefit of SOA is the enablement of business agility – the ability of an enterprise to respond quickly and effectively to customer and market demands. SOA also facilitates cost savings by being able to leverage the existing value of prior technology and legacy systems.

SOAs facilitate the intra-organizational integration of disparate services. On the basis of a central integration layer, often referred to as ESB, heterogeneous applications 44

can be encapsulated and composed (Schroth & Janner, 2007). However, while SOA can be used to describe services and their interactions, it is not seen as a complete software development solution. As stated by Sanders et al. (2008), “One misconception held is that

SOA describes a complete architecture however in reality, SOA is not an architecture but an architectural design pattern from which an infinite number of architectures can be derived. SOA is best suited to be teamed with an architecture framework”.

According to Bell (2009), SOA projects need to be built on a sound foundation of analysis that identifies problem domain including verification of the constructed services against business requirements and technological specifications. Bell also stated that there was a need to assess the feasibility of the proposed solution, and that service discovery and service identification should persist throughout the life cycle with justification of service existence.

There are functional and non-functional aspects to SOA. The functional aspects of

SOA look at the business logic whereas the non-functional looks at elements such as security and other performance measures. A major concern of SOA is security as it is more difficult to secure an open system like SOA as opposed to a closed system like SPL.

One major limitation of SOA (and Web services as we will see later) in that service discovery is not automatic.

SOA Contribution. In this section, we discussed SOA and saw that SOA offers a paradigm for organizing, designing, developing, deploying and managing services to meet business functionalities. We came across the view that SOAs should be built on a sound foundation of analysis that identifies the problem domain and with verification of the services against business requirements and specifications. Although 45

SOA provides the framework for organizing business functionalities as services which can be composed into business processes, it is not considered to constitute a complete software development solution but is best suited to be teamed with an architectural framework (such as SPL). As seen with an SPL implementation (discussed earlier), great importance is also placed on problem domain analysis for an SOA implementation.

In an SPL implementation that integrates SOA, SOA would provide a modular architecture of conceptual services that are associated with the features identified in a problem space feature model, and hence can be viewed as contributing to defining the problem domain architecture or problem space. However, the modular architecture of services provided by SOA also facilitates exposing a domain’s features as services and annotating services with description for discovery, composition and execution, and can be seen as contributing to the solution space.

Recent and current trends have seen the alignment of SOA with other emerging technologies and concepts such as business process management, MDD and SPL. It is therefore an important part of this research to explore the integration of SOA with these and other technologies for a feasible and complete SOA-based solution. Considering the complexity of a SOA, we are faced with questions such as: How can automation of SOA be achieved? How feasible is a ‘semantically annotated’ SOA for the dynamic description, discovery and invocation of services? What is SoaML (Service-oriented architecture modeling language)? What is the role of MDD towards achieving automation in SOAs?

Service Modeling with SoaML. This section looks at the modeling of services in an SOA context. SoaML (OMG, 2009c) is discussed as a solution that bridges 46

the gap between MDD and SOA (including BPM), which can be applied to the solution space of an SPL implementation.

SoaML was adopted in 2009 by the OMG (Casanave, 2009), and is designed to support SOA best practices while normalizing divergent terms and notations. SoaML extends UML to form the standard UML profile for modeling services and SOAs. SoaML provides the capability to create and leverage an architecture that helps people, organizations and systems collaborate via services and shows how those services connect to other parts of the architecture, such as processes, information and business rules

(Casanave, 2009).

SoaML bridges the gap between SOA, BPM and MDD by providing a technology-independent and vendor-neutral modeling tool that shows an entire SOA, that is, how the services and service participants work together to provide business value.

However, according to Casanave (2009), “by design, SoaML is not a complete SOA solution. It provides the capability to model an SOA at the enterprise, system and systems of systems levels. Using the MDA techniques of the OMG, SoaML models can be used to implement SOA solutions on top of popular SOA technology standards such as Web

Services, Enterprise Service Buses, Application Servers and Business Process Execution suites.

Xu, Bai, Berre and Brovig (2010) stated that the goals of SoaML are to support the activities of service modeling and design, and to fit into an overall MDD approach.

They proposed a tool developed on Eclipse platform, for the semantic annotation of service models which uses SoaML as the modeling language (for service-oriented systems) and Ontology Definition Metamodel (ODM). Kou, Babar and Sangroya (2010) 47

refined or extended the SoaML metamodel with QoS concepts in their proposed

SoaML4Security which introduced modeling of the non-functional aspect of security in

SOA. The following are some ways that Enterprise SOA and SoaML provide business value (Casanave, 2009):

• Service modeling at the business level – understanding the enterprise as it

provides and uses services in the supply chain as well as between departments

• Service modeling at the systems level – understanding how the “system of

systems” within the enterprise as well as outside of the firewall work together

as a coherent solution

• Modeling Service Contracts and Service Interfaces to define the roles,

interfaces, message data of services

• Modeling service “choreography”, the ordering of messages within a service

• Modeling services of various complexity and scope: from a simple service

operation to rich bi-directional and asynchronous enterprise scale services

• Automation of the development, testing and maintenance processes with

MDA to reduce development and maintenance costs while improving agility

The lack of comprehensive methodological approaches that support all phases of a service oriented system engineering process in an integrated efficient manner was the motivation for the Semantically-enabled Heterogeneous Service Architecture and

Platforms Engineering - SHAPE Project2 (Berre et al., 2008).) The SHAPE Project has defined an MDE tool-supported methodology for SHA (Semantically-enabled

2 http://www.shape-project.eu/.

48

Heterogeneous service Architecture) which is centered on SoaML and which aims at providing a common modeling language to business and system architects. The SHAPE project aims to support the development and realization of enterprise systems based on a

SHA. SHA extends SOA with semantics and heterogeneous infrastructures (Web services, Agents, Semantic Web Services, P2P and Grid) under a unified service oriented approach.

Hahn et al. (2009) presented conceptual mappings between SoaML model and models from the different abstraction levels in an MDA architecture including BPMN model at the CIM level and WSMO model at the PSM level, which can be used for model-to-model transformation. Incorporating the use of business modeling formalisms such as BPMN that maps to SoaML will enable the alignment of business requirements and IT system implementations. It was also noted by Hahn et al. (2009) that “a mapping from SoaML and WSMO can be meaningful as WSMO is more expressive than SoaML”.

Hahn et al. (2009) provided descriptions of the mappings between SoaML and

WSMO elements, some of which are provided below.

Agent element in the SoaML represents user and maintains the life-cycle of the user requirements and preferences. WSMO uses the notion of Goal for representation of the user requirements.

Capability element in SoaML is used for defining behaviour of the system regardless of its implementation. WSMO Web Service description also includes capability element that is used to describe the function of service.

49

Port element specifies which particular services from the service providers are to be used,

ServicePoint element (both in SoaML) describes the connection point through which a user offers its capabilities and provides a service to clients.

Table 1 provides a conceptual view of the mappings of the elements of SoaML with WSMO:

Table 1 - Conceptual mappings between SoaML and WSMO (Hahn et al., 2009)

SoaML WSMO

Agent Goal

Attachment Goal

Capability WS Description (Capability)

Port WS Description

MessageType Ontologies

RequestPoint WS Description (Grounding)

ServicePoint WS Description

ServiceContract WS Description (Choreography)

In WSMO, Web Service descriptions use two elements: capability and interface for these functions. MessageType in SoaML is used to describe the message itself that is exchanged between the service requestor and service provider. Ontologies are used in

WSMO in order to describe the complex or composite structure of the messages in a meaningful way. ServiceContract element in SoaML is the formalization of a binding exchange of information, goods, or obligations between service consumer and service 50

provider. This information is referred to as Choreography as a part of WS description in

WSMO.

The mappings and correlations between the SoaML model and WSMO can be exploited for a transformation of SoaML description to WSMO description of service.

The formal language used for describing the WSMO based service is WSML, which is then executed by WSMX. Elvesæter, Panfilenko, Jacobi and Hahn (2010) defined a set of model transformation rules that can be used to map BPMN models to SoaML models.

The applications of their proposed mapping rules were tested in industrial use cases in the

SHAPE project. The authors indicated that further work is needed to identify and describe additional patterns and guidelines for mapping to service contracts.

Web Services. While SOA technology has been around for many years,

Web services technology is relatively new. Web services are so named because the services are accessed from the World Wide Web (Web) and Internet network using Web technologies (Internet protocols and standards). The underlying architecture of Web services is based on the concept of SOA, which makes Web services the most mature realization of SOA. A ‘Web service’ inherits the generic characteristics of an SOA

‘service’ but while in SOA the message format is unspecified, for Web services all messages exchanged must be in SOAP format and as such SOAP is seen as the “de facto standard message transfer protocol for cross-platform message-level interoperability and is universally supported” (Parastatidis et al. 2005).

51

Booth, Haas and McCabe et al. (2004) of the World Wide Web Consortium (W3C)3,

Web Services Architecture Working Group, define a Web service as “a software system designed to support interoperable machine-to-machine interaction over a network”. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using

SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” Another definition offered by Austin,

Barbir, Ferris and Garg (2004) is “a Web service is a software system identified by a

URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols”.

As information technology evolves, more businesses are supporting the adoption of cutting edge and emerging technologies to improve business processes, reduce cost and gain competitive advantage. Web services have emerged as a technology that can provide the basis for the development and execution of business processes that are distributed over the Internet. Web services being SOA-based inherit characteristics such as being loosely coupled, reusable and interoperable. Web services share the properties of services already discussed under SOA. Some additional properties of Web services as stated by Wahli et al. (2006) are - modular, inherently open and standard-based, provide

3 http://www.w3.org/

52

the ability to wrap existing applications, built on proven and mature technology, can be published, located, and invoked across the Web.

Web services address heterogeneity problems by enabling the integration of applications developed with one or more technologies through the use of standards which establish commonality in communication language, format for message exchange, language for describing services and a method for registering and discovering services.

While these standards address the abovementioned heterogeneity problems, according Roshen (2009), Web services do not address two additional heterogeneity problems - protocol mismatch and message format mismatch. Roshen (2009) also indicated that Web services integration is “point to point”, requiring a separate connection for each pair of application in an enterprise system. However, while a point- to-point approach may be suitable for small organizations consisting of a few applications, it has limitation in scalability which becomes more apparent and problematic to integrate larger number of applications in large enterprise systems, as

N(N-1)/2 connections are required in a system with N applications. Roshen (2009) discussed the applicability of ESB as a solution to these three issues, namely, protocol mismatch, message format mismatch and scalability. With ESB technology, core functionalities can be included to provide protocol transformation facility and data or message transformation. Applications do not interact directly with each other but instead, connect to the bus, which provides the means for connections among the applications. As such, ESB provides a comprehensive, scalable way to connect a large number of applications without the need for each pair of applications to make a direct connection.

53

Although Web services have benefits such as interoperability and facilitate the sharing of information between business entities, there are some limitations. One of its primary limitations is that the discovery of registered services is not automated (unless requester and provider agree on format for exchange) and as such, requires human intervention. As stated by Booth et al (2004) “in order for the message exchange between requester and provider to be effective, they must be aware of each other and both need to have a common understanding or expectation for the semantics and service descriptions that will be used in the exchange”. Semantic Web Technologies (Herman, Hawke,

Prud’hommeaux & Swick, 2011) addresses this limitation with the addition of semantic annotations to Web services for automated discovery.

Web Service Architecture Stack. The standard protocols responsible for interoperability of Web services are shown in Figure 7.

Figure 7 - Web Services Architecture stack (adopted from Booth et al., 2004, W3C)

54

Web Service technology is founded on XML and HTTP and uses three core standards -

SOAP, WSDL and Universal Description, Discovery, and Integration (UDDI). The core standards along with XML are discussed next following the overview of the stack layers.

Web Services Architecture (Technology) Stack Overview (Studer et al., 2007):

• The “Communications” layer; is the basis for all other layers. It comprises generic

transport mechanisms that can be used to send messages over the Internet. The

most popular binding by far is SOAP-over-HTTP because HTTP is ubiquitously

available and has addressing and error-handling functionalities suited for SOAP

• The “Messages” layer; this is where the core technology of Web Services is

located. It provides basic functionalities for encapsulating network messages in a

neutral way that is independent from a certain programming language or

operating systems and processes. It is divided into a SOAP layer; which provides

a framework for packaging and exchanging XML messages and a SOAP

Extensions layer; provides additional protocol features, such as reliable message

transport or support for transactions

• The “Descriptions” layer; this is where we find technologies that are used for

describing Web Services in a formal way to give Web service consumers exact

access parameters such service location, supported data types and operations. The

most widely used solution here is the Web Service Description Language

(WSDL). WSDL covers only the technical but not the semantic description of a

service which machines need to be perform automatic discovery of services

• The “Processes” layer; this is the top most layer. Responsible for service

discovery, Web Service aggregation or Web Service composition 55

The Web Services Core Standards (XML, SOAP, WSDL, and UDDI) are discussed next:

XML (eXtensible Markup Language) is the markup language that underlies most of the specifications used for Web services. XML is a generic language that can be used to describe any kind of content in a structured way (Wahli et al., 2006).

XML has become the de facto standard for describing data to be exchanged on the

Web. XML tags are used to "mark up" or describe the contents of a document, identify information in a document and the structure of the information. An XML document is typically associated with a schema that specifies its “grammar rules”, that is, tags which are allowed in the document, structure of the tags and other rules about the tags. Because valid XML documents must be well-formed and conform to the associated schema, it makes it relatively easy to process XML documents. As a result, XML has been generally adopted as the data language for Web services (Ort, 2005). The use of XML tags adds flexibility to data content. XML has revolutionized the way data is exchanged and represented across the Web. It provides a standard language for describing document types in any arbitrary domain, facilitating the sharing of data across different systems and, most notably, the Web. XML is flexible and extensible, allowing users to create their own tags to match their own specific requirements. As a result XML-based languages have been designed for use in many different fields.

SOAP. SOAP is an XML-based protocol for exchanging information in a decentralized distributed environment. It uses XML to provide a standard, extensible, messaging framework for packaging a message construct that can be exchanged over a variety of underlying protocols such as HTTP, SMTP, FTP and RMI/IIOP. The

56

specification (of SOAP Version 1.2) consists of three parts. Part 1 defines the SOAP messaging framework consisting of (Gudgin et al., 2007):

• SOAP processing model which defines the rules for processing a SOAP message

• SOAP extensibility model defines the concepts of SOAP features and SOAP

modules and is concerned with providing extensibility

• SOAP underlying protocol binding framework describes the rules for defining a

binding to an underlying protocol that can be used for exchanging SOAP

messages between SOAP nodes

• SOAP message construct defining the structure of a SOAP message

A SOAP message consists of a mandatory SOAP envelope with a value for namespace, such as, "http://www.w3.org/2003/05/soap-envelope". The envelope contains optional

SOAP header(s), and a mandatory SOAP body. The XML Information Set (XML Infoset) of a SOAP Message must correspond to an XML 1.0 serialization.

Figure 8 shows Schematic view with XML representation of a SOAP message structure.

Figure 8 - SOA Envelope (adopted from Studer et al., 2007) 57

WSDL (Web Services Description Language) is an XML-based description language that contains descriptions on the interfaces of Web services. WSDL is used to inform service requesters of the format to be used when requesting a service.

The service provider uses a WSDL document in order to specify the operations a Web service provides and the parameters and data types of these operations. A WSDL document also contains the service access information (Wahli et al. 2006).

WSDL describes Web services’ messages that are exchanged between the requester and provider. The messages themselves are described abstractly and then bound to a concrete network protocol and message format. Web service definitions can be mapped to any implementation language, platform, object model, or messaging system.

As long as both the sender and receiver agree on the service description, the implementations behind the Web services can be anything (Booth et al., 2004,). WSDL is used to describe both interface and implementation details of Web services.

WSDL defines an XML schema for describing a Web service. To uncover the description for a Web service, a client needs to find the service's WSDL document. One way to do this is for the service client to find a pointer to the WSDL document in the web service's registration, which is usually found in a UDDI (or other) registry (Ort, 2005).

Web Services also offer the separation of interface from implementation through the

WSDL descriptions. The definition part of a WSDL document defines the datatypes, messages and operations that together define how to access the functionality offered by the service. WSDL also has a section for binding descriptions. This defines the Web location at which the service can be accessed in addition to the communication and message protocols that should be used for message exchange (Kashyap, Bussler & 58

Moran, 2008). The WSDL is the primary interface artefact for an SOA Web service which functions to expose the functionality of the service as operations, among other things.

UDDI (Universal Description, Discovery, and Integration) defines how to publish and discover information about Web services in a UDDI-conforming registry. A

UDDI registry provides information about a service such as the name of the service, a brief description of what it does, an address where the service can be accessed, and a description of the interface for accessing the service (Ort, 2005). For Web services to be meaningful there is a need to provide information about them beyond the technical specifications of the service itself. According to Clement, Hately, von Riegen and Rogers

(2004), UDDI performs a key function in this regard in its representation of data and metadata about Web services. Businesses and providers can therefore use UDDI to represent information about Web services in a standard way such that queries can then be issued to a UDDI Registry at design-time or run-time that address the following scenarios

(Clement at al., 2004):

• Find Web services implementations that are based on a common abstract interface

definition

• Find Web services providers that are classified according to a known

classification scheme or identifier system

• Determine the security and transport protocols supported by a given Web service

• Issue a search for services based on a general keyword

• Cache the technical information about a Web service and then update that

59

In addition to the concepts and tasks that are located on the different layers in the Web

Service Technology Stack, there are some issues that are relevant to all layers. The most important one is certainly Security: WS-Security (Lawrence & Kaler, 2006), provides a comprehensive security framework that is based on two other W3C standards or core components, namely XML Encryption and XML Signature. Management (Booth et al.,

2004) is also relevant to all layers of the Web Service technology stack. Since the Web

Service technology primarily targets the domain of business applications, where the availability and reliability of a service might be crucial, it is very important that there are capable measures for monitoring and controlling the state of a Web Service. It is also desirable that the service provides a certain QoS, such as, by sending back query results within a given time interval (Studer et al. 2007). Some additional features of Web services are: WS-BPEL which is a layer on top of WSDL and WS-Transaction which specifies a protocol for the long running transaction model defined in WS-BPEL.

WS-BPEL. Web Services Business Process Execution Language, also identified as BPEL4WS, or simply BPEL, is an XML-based language that is used to coordinate web services across a single business process (Jordan & Evdemon, 2007).

WS-BPEL uses WSDL to describe the web services that participate in a process and how the services interact (Ort, 2005). We saw earlier that a service in an SOA either performs a single function or is “coarse grained”, that is, it performs a related set of business functions. Web services that perform a single function are hereby coined as being ‘single- grained’. On the premise that Web services are used to provide business functionalities, we can state that - single grained Web services perform a single business function and coarse-grained Web services are formed from a combination of single-grained and 60

course-grained Web Services, which are joined together in a coordinated way to perform a more complex business function. The composition of two or more Web services to realize a business functionality requires an execution order to determine how and when the collection of Web services is executed. This order of execution bears similarities to process flow diagrams and the results is a business process. The process of composing and coordinating Web services to perform a business process is called “Orchestration”.

Leymann and Roller (2002) stated that “BPEL is an orchestration language which allows specifying business processes and how they relate to Web services. This includes specifying how a business process makes use of Web services to achieve its goal, as well as specifying Web services that are provided by a business process”.

BPEL is based on WSDL, XML Schema, and XPath. Defining a business process collaboration requires that activities be defined and message exchange (with the involved services) be specified. WSDL provides the basic technical description and specifications for messages that are exchanged however BPEL handles the details of collaboration and interactions, which include the following tasks (Jordan & Evdemon, 2007):

• Describing complex compositions of multiple services, which usually consist of

several messages exchanged in a well-defined order

• Handling of faults and other exceptional situations.

• Composition of larger business processes out of smaller processes and services

• Invoking service operations in sequence or parallel

• Scheduling activities based on the execution time and define order of execution

• Executing activities in parallel and defining how parallel flows merge based on

synchronization conditions 61

BPEL was noted by Ouyang, Dumas, ter Hofstede and van der Aalst (2006b) as the emerging de facto standard for implementing business processes on top of Web services technology. The most important part of BPEL is its activities constructs for invoking services. BPEL also offers constructs, such as loops, branches, variables and assignments.

These allow for defining business processes in an algorithmic way. BPEL can be used to define executable business processes. Such processes can be executed on a BPEL Engine.

Each BPEL process consists of a main activity. Activities are steps of the process and include invoke, receive, reply, assign, pick, faultHandler, throw, wait, scope, switch and terminate. BPEL activities can also be structured which include: sequence, flow, decision or loop (Jordan & Evdemon, 2007).

BPEL is a layer on top of WSDL that uses WSDL to specify business process actions and to describe the Web services provided by a business process. WS-Transaction specifies a protocol for the long running transaction model defined in BPEL as well as atomic transactions between regular Web services (Leymann & Roller, 2002). Figure 9 shows the relationship between the standards in Web services and BPEL.

Figure 9 - WS-BPEL layered standards

62

BUSINESS PROCESS MANAGEMENT (BPM)

To succeed in the current globalize economy, businesses have been using information technology IT to optimize business processes towards achieving goals such as - high efficiency, reduced costs and competitive advantage. BPM is defined by Cummins (2008) to be “a management discipline that focuses on the design of business processes and continuous improvement of the speed, cost, and quality of business operations”. Juric and

Pant (2008) stated “BPM fosters business effectiveness and efficiency while striving for innovation, flexibility, and integration with technology. The major objective of BPM is to continuously improve the processes, both within the company and with other companies

(such as in supply chain management)”. Wolf and Harmon (2006) indicated that historically the two leading business drivers for BPM are – the need to save money; and the need to improve an existing process or to create a new business process. (A business driver refers to a situation or goal that motivates management to support business process change).

BPM is an effective model for consumer-to-service interaction in which sets of services are referenced as complete business processes. BPM will invoke a set of SOA services as part of an orchestration or choreography from the BPEL script (Jordan &

Evdemon, 2007). The messages of those service interactions will be passed to endpoints on the ESB for routing to the target services.

BPM is the link that bridges the gap between IT and business operations with a top-down modular approach to developing business processes and manage how organizations design, model, execute, monitor and optimize their business processes. A

63

business process consists of a set of coordinated activities or services that accomplish a particular business function. With respect to Web services, we saw the Orchestration

(composition and coordination) of Web services to perform business processes. The stages in a BPM lifecycle are shown in Figure 10.

Figure 10 - BPM lifecycle

In today’s changing economy, businesses need to be able to adapt quickly to changes in the market place and to ever-changing users’ requirements. As business requirements change, business processes need to change to keep in-line with market trends, customers’ demands or whatever is the catalyst of change. Organizations need an architecture that is flexible and adaptable to the dynamic nature of business process.

The integration of business process management with SOA will be looked at later in this chapter.

Business Process Modeling. Business process modeling involves the development of a process flow model that represents the business process in detail. MDD plays an integral role in modeling business processes. Business process modeling needs to identify what activity initiates the business process, order of activities, outcomes of

64

business process and who performs the activities. The main objective is to develop a business process model, which defines the existing process flow in detail. As such, business analysts, process owners, process analysts or anyone with expert knowledge of business operations are best suited to handle this work. It is imperative that an understanding of the existing process flow (process to be replaced) is obtained to be able to judge the efficiency and the quality of the business process.

While there are many different process modeling tools and methodologies that can be used to represent or model a business process, this report will focus on Business

Process Modeling Notation (BPMN), which was developed by the Business Process

Management Initiative (BPMI) and is the standard accepted by the OMG. (OMG, 2009a)

BPMN provides a Business Process Diagram (BPD), which is a diagram designed for use by the people who design and manage business processes. BPMN also provides a mapping to an execution language of Business Process Management Systems -

BPEL4WS (OMG, 2009a). Thus, BPMN provides a standard visualization mechanism for business processes defined in an execution optimized business process language. With

BPMN, businesses have the capability of understanding their internal business procedures in a graphical notation that is more easily understood, and organizations have the ability to communicate these procedures in a standard manner. Using a standard graphical notation facilitates understanding of the performance collaborations and business transactions within and between the organizations so businesses are better equipped to understand their own processes and participants in their business. It also enables organizations to adjust to new internal and external (business-to-business or

B2B) business circumstances more quickly. BPMN follows the tradition of flowcharting 65

notations for readability while still providing a mapping to the executable constructs.

BPMI uses the experience of the business process notations that preceded BPMN to create the next generation notation that combines readability, flexibility, and expandability (OMG, 2009a).

BPMN provides the standard by which business processes can be modeled and managed. It also has a natural mapping to business execution languages such as BPEL. A benefit to modeling that is exploited in simulations is that through modeling, business processes can be more easily visualized resulting in more accurate representation and alignment of business processes with organization operations and goals. It is this ease of use that has contributed to the adoption of the BPMN by both technical and non-technical users. There are three basic types of sub-models within an end-to-end BPMN model

(White, 2004; OMG, 2009a):

• Private (internal) business processes: these are internal to a specific organization

and are usually called workflow or BPM processes. Each private business process

has separate mappings to BPEL4WS

• Abstract (public) processes: represent the interactions between a private business

process and another process or participant. The abstract process shows to the

outside world the sequence of messages that are required to interact with a

business process. A single abstract process may be mapped to a single BPEL4WS

abstract process (this is not available in BPMN Version 1.2).

• Collaboration (global) processes: a collaboration process depicts the interactions

between two or more business entities. A sequence of activities represents the

message exchange patterns between the entities involved. The collaboration 66

process can be shown as two or more abstract processes communicating with each

other. A collaboration process can be mapped to Collaboration models such as

ebXML BPSS, RosettaNet, and the W3C Choreography Working Group

Specification (when it is completed - not available in BPMN Version 1.2)

The four basic categories of elements in a BPD are: Flow Objects, Connecting Objects,

Swimlanes and Artefacts. The diagrammatic representations of these elements are shown in Figure 11.

Figure 11 - BPD Core Elements (adopted from Juric & Pant, 2008)

Flow Objects are the main graphical elements to define the behaviour of a Business

Process. There are three types of flow objects - Events, Activities (Tasks) and Gateways.

Events represent the various states relevant for the business process, such as start and end. Activities denote the work conducted as part of the business process. Gateways are used to represent the decisions points where a split or join takes place in the flow of control. Flow Objects (and other objects) are connected using three different types of connecting objects - Sequence Flow, Message Flow and Association. Pools and Lanes 67

are the two types of swimlanes used to group the primary modeling elements. Swimlanes represent the organizational relationships within a BPD. Pools usually represent the organizations that interact in a business process, while lanes denote the various departments within an organization. Artefacts are used to show additional information about a business process. These elements include data objects, text annotations and groups. An example BPD is shown in Figure 12.

Figure 12 – Business Process Diagram (adopted from White, 2004)

The diagram above shows some of the core elements of a business process diagram. The collaboration business process has two private (internal) business processes; shown as swimlanes Patient and Receptionist/Doctor process is depicted using sequence and message flows. A patient will start the process by sending a request to a receptionist to see doctor, seen as message flow 1) I want to see doctor sent to the Receptionist/Doctor pool. The process continues with a series of activities and message flows between the

68

participants, which is terminated when the patient receives the medicine sent by the

Doctor.

Dijkman, Dumas and Ouyang (2008) considered that there was a lack of tool support for checking the correctness of BPMN models from a semantic perspective which led to their proposal of a mapping from BPMN into Petri Nets toolset for the purpose of performing semantic analysis of business process models in BPMN using their own

BPMN metamodel in the absence of a standardized BPMN metamodel.

The ultimate objective in the use of IT in business operations is to automate the entire business process. However, according to Hepp, Leymann, Domingue, Wahler and

Fensel (2005), Business Process Management lacks the expressivity and logics-based representation to be accessible to machine reasoning, which translates to low automation.

Greater automation can be achieved in BPM with the use of Semantic Web technologies.

According to Pedrinaci, Domingue and Brelage (2008), “the lack of automation in the business process management lifecycle impedes the scalability of businesses from a management perspective”.

BPM Contribution. As discussed previously, a business process consists of a coordination of services to satisfy a business function and business process management provides an approach to managing business processes that leverages SOA technologies and contributes to SOA success. Business process models can be used to represent the business functionalities and business process flow in a graphical and easily understood format. These functionalities or services represented in the business process model should be traceable back to the problem space feature model. We also saw earlier

69

the SOA contribution to an SPL implementation. When integrated with SOA, business process management can be seen to contribute to the solution space.

THE SEMANTIC WEB

The Semantic Web was originally envisioned by Berners-Lee, Hendler and Lassila

(2001) as an augmentation or extension of the current Web in which information is given well-defined meaning, better enabling computers and people to work in cooperation. Data

(on the Semantic Web) is made machine-readable, from the addition of semantics, to enable automatic processing or machine-to-machine exchange of web content. As stated by (Kashyap et al., 2008) “Semantic annotation of web data makes it possible for computers to understand the meaning of data and make more accurate decisions on how that data should be processed. This means that the data is expressed in a language based on some type of formal logic that a computer can reason over. The computational device that carries out this task (of reasoning) is usually referred to as a reasoner”.

The Semantic Web is considered to be a solution to problems such as heterogeneity, interoperability and integration that is usually experienced in distributed systems. Special technologies and standards are required to enable the creation of data sources, incorporation of metadata into data sources, building of vocabularies and writing of rules for querying and handling data. The Semantic Web provides the necessary infrastructure for publishing and resolving ontological descriptions of terms and concepts. In addition, it provides the necessary techniques for reasoning about these concepts, as well as resolving and mapping between ontologies, thus enabling semantic 70

interoperability of Web Services through the identification (and mapping) of semantically similar concepts (Cabral, Domingue, Motta, Payne & Hakimpour, 2004).

The main areas of Semantic Web are Linked Data, Vocabularies, Queries,

Inference and Vertical Applications (W3C, 2010a). These are described below along with the associated technologies (W3C, 2010a):

Linked Data. The Semantic Web is a Web of Data. This data and the relationships among the data need to be in a standard format to be accessed and processed by Semantic

Web technologies such as RDF, POWDER and SPARQL. This collection of interrelated datasets on the Web is referred to as Linked Data. To achieve and create Linked Data, technologies should be available for a common format - RDF, to make either conversion or on-the-fly access to existing databases (relational, XML, HTML, etc). Linked Data lies at the heart of what Semantic Web is all about: large scale integration of, and reasoning on, data on the Web. (W3C, 2010a)

RDF. The Resource Description Framework (RDF Working Group, 2004) is a framework for representing information in the Web. RDF is a standard model for data interchange with features that facilitate data merging even if the underlying schemas differ, and it specifically supports the evolution of schemas over time without requiring all the data consumers to be changed. RDF extends the linking structure of the Web to use URIs to name the relationship between things as well as the two ends of the link (this is usually referred to as a “triple”). Using this simple model, it allows structured and semi-structured data to be mixed, exposed, and shared across different applications. RDF provides the foundation for publishing and linking data. On the Semantic Web,

71

vocabularies define the concepts and relationships (“terms”) used to describe and represent an area of concern.

Vocabularies. Vocabularies are used to classify the terms that can be used in a particular application, characterize possible relationships, and define possible constraints on using those terms. In practice, vocabularies can be very complex (with several thousands of terms) or very simple (describing one or two concepts only). There is no clear division between what is referred to as “vocabularies” and “ontologies”.

Vocabularies help data integration when, for example, ambiguities may exist on the terms used in the different data sets, or when a bit of extra knowledge may lead to the discovery of new relationships. As such they are the basic building blocks for inference techniques on the Semantic Web. (W3C, 2010b)

An example given by W3C (2010b) to illustrate this area of the Semantic Web, was the application of ontologies in the field of health care. Ontologies are used by medical professionals to represent knowledge about symptoms, diseases, and treatments and by pharmaceutical companies to represent information about drugs, dosages, and allergies. The combination of the knowledge from the medical and pharmaceutical communities with patient data enables a whole range of intelligent applications such as decision support tools that search for possible treatments; systems that monitor drug efficacy and possible side effects; tools that support epidemiological research; and systems such as electronic prescription that improve patient care and reduce adverse drug reaction. To satisfy these different needs, W3C offers a large palette of techniques to describe and define different forms of vocabularies in a standard format. These include

72

RDF and RDF Schemas (RDFS)4, Simple Knowledge Organization System (SKOS)5 and

Web Ontology Language (OWL)6 to define ontologies and the Rule Interchange Format

(RIF)7 to cover rule based approaches (W3C, 2010b).

Query. Query in the Semantic Web context, means technologies and protocols that can programmatically retrieve information from the Web of Data.(W3C, 2010c)

“Query” uses SPARQL (Prud'hommeaux & Seaborne, 2008 ) an RDF-specific query language. SPARQL makes it possible to send queries and receive results, e.g., through

HTTP or SOAP.

Inference. Inference with respect to the Semantic Web can be characterized by

“discovering new relationships”. On the Semantic Web, data is modeled as a set of

(named) relationships between resources. “Inference” means that automatic procedures can generate new relationships based on the data and based on some additional information in the form of a vocabulary. Inference on the Semantic Web is one of the tools of choice to improve the quality of data integration on the Web, by discovering new relationships, automatically analyzing the content of the data, or managing knowledge on the Web in general. Inference based techniques are also important in discovering possible inconsistencies in the (integrated) data. (W3C, 2010d) An example or a medical scenario will be used to illustrate inference; Data shows: ‘Patient-A has factor VIII deficiency’

4 http://www.w3.org/standards/techs/rdf#w3c__all

5 http://www.w3.org/standards/techs/skos#w3c__all

6 http://www.w3.org/standards/techs/owl#w3c__all

7 http://www.w3.org/standards/techs/rif#w3c__all

73

and from medical Ontology: ‘Haemophilia B is_a (caused from) factor VIII deficiency’.

The new relationship ‘Patient-A has Haemophilia B’ can be discovered using

Inferencing.

Vertical Applications. Vertical application (W3C, 2010e) is the term used to denote particular, generic application areas or specific communities that explore how

W3C technologies such as Semantic Web technologies, can help their operations, improve their efficiencies and provide better user experiences. Examples for such vertical applications that have contact with W3C on different levels are health care and life sciences, social spaces, digital libraries, financial services, oil & gas exploration, or e-

Government. Apart from the inherent advantages for a particular vertical application area to get a better familiarity with a particular W3C technology, these groups also provide valuable feedbacks on the technologies themselves. The Health Care and Life Science

Interest Group (HCLS)8 W3C (2005), was recognized by the W3C as an example of a vertical application (W3C, 2010e). HCLS was established in 2005 to explore the usability of Semantic Web technologies in area like drug discovery, patient care management and reporting, publication of scientific knowledge and drug approval procedures. The feedbacks provided by this group was also significant for Semantic Web technologies; as an example the definition of some of the OWL2 Profiles was strongly influenced by the ontologies and vocabularies developed by this community.

Semantic Web Services. The evolution of Semantic Web Services (SWS) from

Web services and the Semantic Web technologies can be attributed to the growing need

8 http://www.w3.org/2001/sw/hcls/

74

for automation. According to Roman, Lausen and Keller (2006) “Semantic Web services aim at an integrated technology for the next generation of the Web by combining

Semantic Web technologies and Web services, thereby turning the Internet from an information repository for human consumption into a world-wide system for distributed

Web computing”.

As stated by Cardoso (2007) - “Web services provide a foundation for easier system integration by providing a standards-based approach. However, integration and process automation projects are often expensive and time consuming even with Web services, and may not result in solutions that are as flexible and reconfigurable as needed to best react to today's dynamic business environment”. Cardoso (2007) went on to state

“Semantic Web services offer the promise of automating integration tasks which could potentially save development time and reduce implementation costs”. SWS descriptions are ontology-based with the ontology providing the terminologies used to describe a particular domain and the relationship between concepts in the domain. Figure 13 gives a diagrammatic representation of the evolution of Semantic Web Services from semantically annotated Web services.

Figure 13 - Evolution of Semantic Web Services (Cardoso & Sheth, 2006)

75

Semantic descriptions of Web services are necessary in order to enable their automatic discovery, composition and execution across heterogeneous users and domains. A

Semantic Web Service is defined through a service ontology, which enables machine interpretability of its capabilities as well as integration with domain knowledge (Cabral et al., 2004). The annotating of Web services with semantic metadata results in more meaningfully encoded data which means discovery of services will be easier as data can be searched, interpreted and integrated more efficiently. We will now look at some leading ontology-based approaches for representing Semantic Web Services: OWL-S,

SWSF, WSDL-S, SAWSDL and WSMO.

OWL-S. OWL-S is an OWL-based Web service ontology, which supplies

Web service providers with a core set of constructs for describing the properties and capabilities of their Web services in unambiguous, computer-interpretable form. OWL-S markup of Web services will facilitate the automation of Web service tasks, including automated Web service discovery, execution, composition and interoperation. (Martin et al. (2008)

To make use of a Web service, a software agent needs a computer-interpretable description of the service, and the means by which it is accessed. An important goal for

Semantic Web markup languages is to establish a framework within which these descriptions are made and shared. Web sites should be able to employ a standard ontology, consisting of a set of basic classes and properties, for declaring and describing services, and the ontology structuring mechanisms of OWL provide an appropriate, Web- compatible representation language framework within which to do this (Martin et al.,

2004). 76

Following the layered approach to markup language development, the current version of OWL-S (Martin et al., 2008) builds on the Ontology Web Language (OWL)

Recommendation (Dean & Schreiber, 2004). OWL-S is structured into three sub- ontologies, for describing different aspects of Semantic Web Services (Martin et al.,

2004):

The ServiceProfile describes “what the service does”, that is, the functionality or interface a Web service offers and provides the means by which the service can be advertised.

The ServiceModel describes “how it works”, that is, it is used to define the behavioural aspect of the Web Service. This part of the service is modeled as a process in the sense that a service requester can view the process description and understand how to interact with the service in order to access its functionality.

The ServiceGrounding describes “how to access it”, that is, it provides information about how to use a service by providing a link between the ServiceModel and the description of the concrete realization for a Web Service provided by WSDL. That is, OWL-S seeks to build on top of WSDL and SOAP by mapping elements in the ServiceModel to elements in the WSDL description service grounding to provide information about how to use a service (Kashyap et al., 2008).

77

Figure 14 - Top level of OWL-S Service ontology (Martin et al., 2004)

Semantic Web Services Framework (SWSF). Shortcomings of OWL-S as a conceptual model for Semantic Web Services motivated the establishment of the

SWSF.(Battle et al., 2005) SWSF is divided into two parts; Semantic Web Services

Ontology (SWSO) provides a full conceptual model and Semantic Web Services

Language (SWSL) an expressive language to describe the process model of Web

Services. SWSO defines a conceptual model for Semantic Web Services by extending the work of OWL-S to interoperate with and provide semantics for industry process modeling formalisms like the Business Process Execution Language (BPEL). The first- order logic axiomatisation of SWSO is called FLOWS (First-Order Logic Ontology for

Web Services) and is based on the Process Specification Language (PSL) (NIST, 2008), an international standard ontology for describing processes in domains of business, engineering and manufacturing. One of the intentions of PSL was to provide a common interlingua (artificial language) for the many existing process languages, allowing interoperability to be established between them. As the number of conceptual models and languages for Semantic Web Services grows, there is a perceived need for such an

78

umbrella formalism to facilitate interoperability in this area (Kashyap et al., 2008; Battle et al., 2005).

WSDL-S. Is an extension to Web Service Description Language which associates semantic annotations with Web services.(Akkiraju et al., 2005) According to

Kashyap et al. (2008), unlike OWL-S, SWSO and WSMO, WSDL-S does not specify an ontology for the definition of Semantic Web Services. Instead, WSDL-S takes a bottom- up approach with the appeal that potentially only a little additional effort on the part of service producers will provide a service description where the description of the data and operations of the service are bound to ontological concepts. Kashyap et al. (2008) also stated that “WSDL-S intentionally builds directly on the existing Web Service technology stack”. In WSDL-S, users can add semantic annotations to WSDL documents using the extensibility framework defined in the WSDL specification. The semantic annotations could be references to concepts defined in an external ontology. WSDL-S as such does not prescribe any particular ontology language and is defined to be agnostic to the semantic representation language. Users can use OWL or WSMO or any other modeling language of their choice. WSDL-S work came out of METEOR-S (2003) project from University of Georgia, which was later significantly revised jointly by IBM and METEOR-S team (Cardoso, 2007).

SAWSDL. Semantic Annotations for WSDL and XML Schema

(SAWSDL) defines how to add semantic annotations to various parts of a WSDL document such as input and output message structures, interfaces and operations. The extension attributes defined in SAWSDL specification fit within the WSDL 2.0, WSDL

1.1 and XML Schema extensibility frameworks. Many of the concepts in SAWSDL are 79

based on an earlier effort - WSDL-S (Farrell & Lausen, 2007). Web services provide a standards-based foundation for exchanging information between distributed software systems. WSDL specifies a standard way to describe the interfaces of a Web Service at a syntactic level and how to invoke it. However, WSDL lacks semantics which are needed to facilitate automatic discovery, composition and integration of software components.

SAWSDL defines mechanisms by which semantic annotations can be added to WSDL components. Some SAWSDL related terminologies defined by Farrell and Lausen (2007) are as follows: Semantic Model is a set of machine-interpretable representations used to model an area of knowledge. Ontologies are a type of semantic model; Concept is an element of a semantic model that must be identifiable by Uniform Resource Identifiers

(URIs); Semantic Annotation is additional information that identifies or defines a concept in a semantic model. Semantic annotations are of two kinds: explicit identifiers of concepts or identifiers of mappings from WSDL to concepts or vice versa; Semantics refers to sets of concepts identified by annotations.

SAWSDL defines the following extensibility attributes: modelReference is an extension attribute that specify the association between WSDL component and a concept in some semantic model or (domain) ontology. The remaining two schema mapping extension attributes – liftingSchemaMapping and loweringSchemaMapping, are added to

XML Schema element declarations and type definitions for specifying mappings between semantic data and XML. The modelReference attribute can be viewed as the interoperability facilitator for Semantic Web Services in that it allows multiple annotations to be associated with a given WSDL component via a set of URIs. These

URIs may identify concepts expressed in different semantic representation languages. 80

Any mismatch between the semantic model and the structure of the inputs and outputs is resolved with the loweringSchemaMapping – maps semantic data to XML, and liftingSchemaMapping – maps XML to semantic model (Farrell & Lausen, 2007).

SAWSDL is based on WSDL-S and shares two basic annotations – the model reference annotation, which is used to support the discovery of Web Services and for dynamic configuration of Web processes; and the schema mapping annotations which are used to deal with data heterogeneity, particularly transforming one data representation into another Web services (LSDIS, 2005). Akkiraju and Sapkota (2007) states that with

SAWSDL, we can see how ontologies can be integrated in the different stages of Web services development lifecycle: in Development – a service provider can define the intended semantics by annotating the appropriate parts of the Web service with concepts from richer semantic models or ontologies. Ontologies provide agreement on the terms and intended use of terms, and may provide formal and informal definitions of the entities resulting in less ambiguity in the intended semantics of the provider; In Discovery

– a service requester can describe the service requirements using terms from the ontology. Reasoning techniques can be used to find service descriptions that match the request. In Composition – the semantic annotations can be used to aggregate the functionality of multiple services to create useful service compositions. Also, semantics based schema mappings can facilitate data transformations from which mediation code can be generated to enable Web services invocation. Therefore ontologies or semantic annotations can be leveraged by tools to automate service discovery, mediation, composition, invocation and monitoring.

81

Stack of Ontologies. Pedrinaci et al. (2008) described a stack of ontologies proposed by the SUPER Integrated Project (Domingue et al., 2008b) to represent business process knowledge. The stack includes Upper Level Process Ontology

(UPO) which builds upon the use of Web Service Modeling Ontology (WSMO) as the core Semantic Web Services conceptualisation, Business Process Modeling Ontology

(BPMO) and Domain (business) ontologies. Web Service Modeling Language (WSML) is used as the representation language supporting the specification of Ontologies, Goals,

Web Services and Mediators associated with WSMO.

Ontologies are viewed as the core component that provides the required semantic information that enhances the composition, mediation and discovery of Web Services by applying Semantic Web Services techniques (Pedrinaci et al., 2008). In the SUPER

Ontology stack (Domingue et al., 2008a) UPO defines the top-level concepts such as task, goal and condition. BPMO extends the UPO into full process ontology, providing abstractions over different business process modeling annotations such as BPMN.

Figure 15 - Ontology diagram (adopted from Domingue et al., 2008)

82

WSMO. Web Service Modeling Ontology (WSMO) is an ontology for describing various aspects related to Semantic Web Services (Roman et al., 2006). The

WSMO framework extends the Web Service Modeling Framework (WSMF) to develop a formal ontology and language. The appropriate frameworks for Semantic Web services need to integrate the basic Web design principles, those defined for the Semantic Web, as well as design principles for distributed, service-orientated computing of the Web

(Roman et al., 2006). WSMO defines a consistent technology for Semantic Web Services by providing the means for automatic discovery, composition and execution of Web

Services which are based on logical inference-mechanisms.

According to Arroyo, Bussler, Kopecky and Lara (2004), “WSMO defines the modeling elements for describing several aspects of Semantic Web Services”. The authors also stated that “in the context of semantic description and discovery of Web

Services, service capability expresses a provision by either the provider or the requester.

On the provider side, it expresses what the service can offer and on the consumer side it expresses what the client can offer but does not really insist on”. According to De Bruijn,

Kerrigan, Zaremba and Fensel (2009), “in order for the vision of Semantic Web services to be realized, it is necessary to identify all the aspects related to the description of Web services in a single conceptual framework. The Web Service Modeling Ontology is such a conceptual model, it identifies the functional and non-functional aspects of Web service offerings, as well as user requests, to enable their description in an adequate manner”.

WSMO is based on the following design principles (Roman et al., 2006):

83

• Web compliance. WSMO can be serialized to XML, the language of the Web, and

WSMO service descriptions ground to WSDL (Kashyap et al., 2008). WSMO

uses unique identifiers (URIs) for unique identification of resources

• Ontology-based. Ontologies are used as data model to all resource descriptions in

WSMO

• Strict decoupling. WSMO resources are defined in isolation of other resource and

without regard to possible usage.

• Centrality of Mediation. WSMO recognizes the importance of mediation for the

successful deployment of Web services by making mediation a first class

component of the framework. Mediation addresses the handling of heterogeneities

(in data, ontologies, protocols or process) that naturally arise in open

environments to support strict decoupling.

• Ontological Role Separation. In WSMO the service requesters exist in specific

contexts which will not be the same as for available Web services (service

providers). According to Kashyap et al. (2008) “(the) viewpoints of service

requester and service provider are distinctly represented by the complementary

concepts of goals and Web Services. This separation is adopted from the research

in the problem-solving domain and is a clear point of distinction between the

OWL-S and WSMO models”.

• Execution Semantics. In order to verify the WSMO specification, the formal

execution semantics of reference implementations like WSMX as well as other

WSMO-enabled systems provide the technical realization of WSMO.

84

• Description versus implementation. WSMO differentiates between the

descriptions of Semantic Web services elements and executable technologies

(implementation). WSMO aims at providing an appropriate ontological

description model, and be compliant with existing and emerging technologies.

• Service versus Web Service. A Web service is a computational entity which is

able (by invocation) to achieve a users goal. WSMO provides means to describe

Web services and not to replace the functionality of the services.

The top level elements of WSMO are Ontologies, Web services, Goals and

Mediators. These are described below.

• Ontologies provide the terminology and semantics used to define the information

model for all aspects or components of WSMO. In WSMO, ontologies are the key

to linking conceptual real-world semantics defined and agreed upon by

communities of users by providing concepts, and relationships between the

concepts. As stated by Kashyap et al (2008) “Ontologies are only useful if the

meaning they express corresponds to a shared understanding by its users. The

strength of an ontology is that the semantics of its elements are machine-

understandable, made possible through the provision of a mathematical base for

the language used to express the ontology. Ontologies defined in WSMO are part

of the MOF model layer”. The extensive usage of ontologies allows semantically

enhanced information processing as well as support for interoperability (Roman et

al., 2006).

• Web Services describes the computational entity providing access to services that

provide some value in a domain. These descriptions comprise the capabilities, 85

interfaces and internal working of the Web service. WSMO Web service

descriptions consist of non-functional, functional and the behavioural aspects of a

Web service. A Web service is a computational entity which is able (by

invocation) to achieve a users goal. A service in contrast is the actual value

provided by this invocation. Arroyo et al. (2004) stated that “the functional

capabilities are modeled in terms of the pre-conditions and assumptions for the

correct execution of service and the post-conditions and effects resulting from it”.

• Goals represent requesters’ desires which could be achieved by executing a Web

service. Service requesters can specify service requests in their own

terminologies. Service discovery is the term used to indicate that a Web service

was found that satisfies the goal. According to Arroyo et al (2004), Goals provide

the means to express high level description of a concrete task.

• Mediators are WSMO elements that overcome interoperability problems between

different WSMO elements. Mediators are the core concept to resolve

incompatibilities on the data, process and protocol level. There are four types

which are used to bridge interoperability between any two WSMO elements. They

are named based on the elements being mediated between: ggMediators

(mediators that link two goals), ooMediators (mediators that import ontologies

and resolves mismatch between ontologies), wgMediators (mediates between

Web service and goal), wwMediators (mediates between two web services).

86

Figure 16 - The top-level elements of WSMO (Lausen, Polleres & Roman, 2005)

WSMO Execution Environment (WSMX). WSMX is defined as the reference implementation of WSMO and an execution environment for business application integration where enhanced web services are integrated for various business applications. WSMX aims to increase business processes automation in a very flexible manner while providing scalable integration solutions (WSMX, 2008).

WSMX provides middleware functionality designed to take advantage of the semantic annotations of Web Services using the WSMO model. The implemented

WSMX architecture provides an approach to the automated discovery, composition, mediation and invocation of Semantic Web Services (Kashyap et al., 2008). Figure 17 shows a high-level overview of the WSMX architecture.

Figure 17 – WSMX Architecture (adopted from Kashyap et al., 2008)

87

The Semantic Web Contribution. We have discussed Semantic Web technologies and seen that Semantic Web services (SWS) are formed from annotating Web services with ontologies. We saw that the use of ontologies with web services allowed for better description of domains resulting in enhanced knowledge sharing, communication and interoperability. However, as we will see later in this chapter, ontologies can be applied at the different abstraction levels or stages of software development for potentially more wide-scaled automation. We saw Web services as realizations or concrete implementations of SOA, or actual product derivations from an SPL perspective. We can therefore see Semantic Web services as enhanced implementation of SOA and the use of semantic annotations for enhanced interoperability and knowledge sharing. This makes

The Semantic Web and Semantic Web Services key contributors to defining a cutting edge SPL solution space where the use of ontologies contribute to improvement in communication, interoperability and automation.

INTEGRATING KEY TECHNOLOGIES

In this section we will look at examples in literature that showed integrations of the reviewed emerging technologies and discuss the impact of the resulting integration on an

SPL implementation.

SOA/SPL. Cohen and Krut (2010) indicated some benefits of combining service oriented architecture and software product line approaches being: flexible approaches for implementing business processes in an SOA; systematic reuse approaches from software

88

product line (SPL) development. In an integrated service oriented product line (SOPL) approach, developers build core assets – including services; systems are constructed through the systematic reuse of core assets in a predefined way; developers exploit commonality across related products; planned variation is applied among core assets;

SOA is used for flexibility – variation through services that are not bound to a specific product.

Smith (2009) presented an “Intersection between Software Product Lines and SOA”, which shows the features of a combined SPL and SOA:

• software product lines support systematic reuse by using core assets with a

production plan to enable the rapid generation of new products

• SOA exposes services that can be reused by a variety of consumers, enabling:

agility, adaptability, cost efficiency and legacy leverage

• SOA services can become core assets within a product line

• SOA services can provide significant leverage as variability mechanisms in a

product line

From the perspective of a feature model based SPL implementation, we can ascertain that an SOPL framework would apply (primarily) to defining the SPL’s problem space, with the domain features modeled as user-visible reusable core services in the feature model from which products are derived.

SPL/MDD. Czarnecki and Eisenecker (as cited in Gröner, Wende & Boškovi et al., 2011), takes a model-based perspective to SPL with the view that “SPL is typically specified with three kinds of models: problem space models, solution space models, and mapping models”. Gröner et al. (2011) view is that problem space models, which are 89

typically feature models, define the available features and interdependencies between members of the SPL; solution space models, which are usually modeled as business process models or UML models, specify the realization of complete SPL. The variability of the domain (that is reflected in feature models) is also reflected in the solution space models which are usually referred to as model templates. A particular product or configuration is derived from removing or adding parts of the solution space model; and, mapping models define mapping relations between the features selected in the problem space models and solution space models. The authors also proposed a description logics- based approach for the automated validation of the solution space with respect to the feature model (problem space model) and mapping model, in order to identify inconsistencies and achieve well-formedness of SPL models. For traceability between feature models and solution space models and to better facilitate automation, each feature in a feature model would need to be mapped to the realization elements in the solution space models with the mappings clearly expressed to facilitate automatic product derivation.

MDE Integration with other technologies. Brambilla, Ceri, Facca et al. (2007) proposed a model driven approach towards achieving a semiautomatic extraction of

WSMO (Web Service Modeling Ontology) descriptions of Web services from BPMN

(Business Process Modeling Notation) models. The authors believe that model driven software design offers rich model descriptions to support semantic Web service abstractions. The focus of their proposed approach was on a design phase required to provide WSMO compatibility. WSMO was used as a semantic service-modeling framework because it provides a clear separation between well-identified components, 90

such as ontologies, goals, Web services, and mediators, and because it is founded on the two distinct principles of strong decoupling and mediation.

Giner, Torres and Pelechano (2007) demonstrated how to bridge the gap between

BPMN and BPEL using an MDA approach to develop a BPMN2BPEL transformation tool which transform BPMN diagrams into executable WS-BPEL definitions. Montero,

Peña and Ruiz-Cortés (2008) demonstrated the use of Atlas Transformation Language

(ATL) to transform a feature model into BPMN (Business Process Modeling Notation) diagram. James J. Rusk (2009) built on the work of Antkiewicz and Czarnecki (2004) and with a similar approach to Montero et al., presented a proposal that demonstrated the use of ATL to transform a feature model into WSMO. The works of Ouyang et al. (2006a,

2006b) showed the capability of generating readable BPEL code by discovering patterns in the BPMN models that can be mapped onto BPEL block-structured constructs.

Perovich, Rossel and Bastarrica (2009) applied MDE to Domain Engineering to enable automation of Application Engineering by way of a Feature-to-Architecture

Transformation Rule. Some key components of their approach were – features are functional areas; features are used during domain design to structure the architectural components; the product line is developed incrementally and; metamodels are used to abstract away the underlying technology.

Asadi et al. (2009) presented a model driven approach to developing families of

SOAs. They recognized SOA as the most promising paradigm for distributed computing application design and development and saw SPLE as a methodological approach to address variability in the different layers of SOA development. MDE was integrated into the architecture with the benefits of abstracting away certain levels of technical details. 91

The combination of SPLE and MDE bridges the gap between business process management and software engineering with an MDA approach to Domain Engineering.

MDD can be applied across the different processes and phases of developing SPLs.

SPL/BPM. Bae and Kang (2007) proposed a method to generate a feature model from a business process model (FMBP). It uses a bottom-up approach starting with the

Business Process Analysis from which Use Cases are derived and then later Feature

Models. This approach is therefore Use Case–oriented (as opposed to feature-oriented) with the Feature Model being the final product. The steps taken in identifying the business process are very similar to what is involved in identifying features using the

FODA methodology and in that regard is seen as applicable to the problem space. Each feature is considered as a group of use cases, associated to perform a specific business activity. There was however not a clear indication of how the process would be automated or what tools or applications ties the BPM and the use cases. The need to develop BPMN that can systematically represent process commonality and to develop methods to analyze commonality and variability was also indicated by the authors.

SOA/BPM. SOA has been identified as an architecture that provides the capabilities for services to be coordinated into business processes for a more adaptable, flexible and agile business (Juric & Pant, 2008). With SOA, companies can optimize their business processes more easily and in a shorter time than with traditional approaches.

From a business perspective, in order to adopt a service-oriented approach to software development, business processes need to be re-structured (re-engineered) into autonomous system components that can then be exposed as services. These services need to use standard messaging and communication protocols to be discoverable. 92

The combination of SOA and BPM requires effective collaboration and communication between business and IT professionals, to realize optimized business operations and the flexibility and adaptability capabilities offered by a service-oriented architecture.

SOA provides an architectural context for business processes that support sharing of optimized processes and the associated capabilities in multiple contexts, producing economies of scale and improved enterprise agility. BPM complements and extends SOA to enable the definition, integration, and continuous improvement of services. SOA brings a fundamental pattern to the design of business processes as business processes do not exist independent of service units, and processes are confined to management of activities within an associated service unit (Cummins, 2008). The following excerpt from a 2007 article in Information Management Magazine brings focus to the benefits of integrating BPM and SOA:

“Driven in large part by the growing adoption rates of a service-oriented

architecture (SOA) strategy, more and more organizations are realizing

that the alignment of IT and business delivers tangible results and

significant returns in terms of productivity, competitive advantage and cost

savings. However companies need to streamline their business processes

to develop and utilize reusable software artefacts in order to seize these

new opportunities and realize the benefits that can be derived from an

SOA.”

93

The rationale to combine SOA with BPM has caused a shift in the role of IT and business and is reflected in the 2010 merger of the BPM and SOA Consortiums (BPM/SOA

Community of Practice (CoP) – OMG, 2010).

Kemsley (2008) discussed two different approaches for integrating SOA and

BPM. A bottom-up approach is one in which the SOA drives BPM, that is, SOA events are performed before BPM events. With this approach, services are developed on schedule, after which, these services are consumed by the business processes. The disadvantage or risk with this approach is that services may get developed which are not yet needed or which may not match the requirements of applications and business goals and also that business process may end up waiting on services. A top-down approach is one in which BPM drives SOA which sees the process modeling followed by identification or building of required services. This approach has the risk of creating services for a particular business process resulting in the loss of reusability as services are made too specific. Kemsley (2008) suggests that a combination of bottom-up and top- down approaches presents a more ideal solution for SOA/BPM integration in which bottom-up planning defines the framework for class of business services that need to be developed and BPM is used to fine-tune requirements for services and dictate order of development of services.

Juric and Pant (2008) discuss the shift from the traditional development approach with the phases: Analysis, Design, Implementation and Testing towards the SOA approach for business process automation which consists of the phases: Modeling,

Composition, Testing and Monitoring. The first step is to identify the business process to be automated, the aim of this step is to first develop processes that have a greater return 94

on investment (ROI) or which stands to benefit the business goals. The Modeling phase refers to business process modeling resulting in process development being better aligned with the actual needs of business using tools such as BPMN. It is important to model the process in detail to be able to identify atomic activities that can be later executed.

Composition refers to the development of reusable services and the orchestration of services into processes. Automation of the process requires mapping the BPMN process into the executable BPEL representation and connecting the BPEL process with services.

Testing SOA applications refers to the testing of processes and associated services.

The integration of SOA and BPM seeks to align IT with business operations, which is applicable to the solution space of an SPL implementation.

Integration with Ontologies. Ontologies are knowledge representations that can be applied throughout the software development process at different levels of abstraction to enhance communication and interoperability, especially in distributed applications, and also to enhance traceability. This section looks at Ontology Definition Metamodel – a realization of integrating MDE and Semantic Web technologies, before looking at the integration of ontology in software development.

ODM (Ontology Definition Metamodel). The ODM standard (OMG,

2009b) can be viewed as a first step towards bridging the gap between MDE and the

Semantic Web which makes the concepts of MDA applicable to modeling ontologies.

According to the OMG: “The (ODM) specification represents the foundation for an extremely important set of enabling capabilities for MDA based software engineering, namely the formal grounding for representation, management, interoperability, and application of business semantics” (OMG, 2009b). The specification defines a family of 95

independent metamodels, related profiles, and mappings among the metamodels corresponding to several international standards for ontology as well as capabilities supporting conventional modeling paradigms for capturing conceptual knowledge, such as entity-relationship modeling. The ODM specification offers a number of benefits to potential users, including (OMG, 2009b):

• Options in the level of expressivity, complexity, and form available for designing

and implementing conceptual models

• Grounding in formal logic, through standards-based, model-theoretic semantics

for the knowledge representation languages supported, sufficient to enable

reasoning engines to understand, validate, and apply ontologies developed using

the ODM

• Profiles and mappings sufficient to support not only the exchange of models

developed independently in various formalisms but to enable consistency

checking and validation in ways that have not been feasible to date

• The basis for a family of specifications that integrate MDA and Semantic Web

technologies to support semantic web services, ontology and policy-based

communications and interoperability, and declarative, policy-based applications

in general.

The ODM is applicable to knowledge representation, conceptual modeling, formal taxonomy development and ontology definition, and enables the use of a variety of enterprise models as starting points for ontology development through mappings to UML and MOF. ODM-based ontologies can be used to support:

• interchange of knowledge among heterogeneous computer systems 96

• representation of knowledge in ontologies and knowledge bases

• specification of expressions that are the input to or output from inference engines

Integrating Ontologies in Software Development. Wang et al. (2005) considers that Semantic Web plays a significant role in domain engineering. They found similarities between Semantic Web ontology and feature modeling which led to their proposal of a Semantic Web approach to feature modeling and verification using Web

Ontology Language (OWL-DL) to represent the feature model and RACER (Renamed

ABox and Concept Expression Reasoner) for verification, that is, to identify inconsistency in configuration. They also found that OWL was not expressive enough and would need to be extended with rules extension languages such as SWRL FOL

(Semantic Web Rule Language First-Order Logic) to deal with large scale and complex feature models. Zaid et al. (2009) proposed a FMO (Feature Model Ontology) to address the need for a formal or standard semantics for validating and integrating feature models.

In their proposed framework the feature model knowledge base is comprised of three elements - FMO is an ontology framework to formally define and represent feature models; the feature model SWRL Rules – used to detect inconsistencies; feature model instances (specializations). The modeling process is performed using OWL as the ontology language, which gives an OWL representation of the knowledge base found in feature models. Their research also indicated the need to develop tool support that allows collaborative analysis, the modeling of feature models and ability to find inconsistencies.

Kaviani, Mohabbati, Gaševi and Finke (2008) propose the use of design-time ontology annotation to extend feature models with attributes to support non-functional requirements (NFRs) in ubiquitous computing systems, to enable high quality service 97

selection and composition based on user requests. The authors believe ontologies provide the appropriate means to bring NFRs into the definition of feature models and validating product specifications with respect to the desired NFRs. The enriched feature models

(annotated with ontologies) allow for analysis and reasoning with OWL language which takes advantages of ontology annotation capabilities. Description Logic which is used as the underlying logic for ontologies helps with validating (non-)functional requirements, product configuration, and product consistency check through ontological reasoning. The authors indicated that although Web Service Modeling Ontology (WSMO) provides a semantic basis for adding non-functional properties to Web services description, the number of NFRs supported by WSMO are limited and cannot be dynamically altered or adjusted at run time. Mohabbati et al. (2009) continued on the previous work by Kaviani et al (2008) and with the view that “feature models lacked the required semantics to incorporate non-functional requirements (NFRs) and enable reasoning over the set of possible products in order to derive the best configurations”, they proposed that Feature

Model Ontology (FMO) which takes advantage of ontology language annotation and other capabilities such as easily expandable and semantically enriched conceptualization methodologies, can be used as the underlying languages for expressing feature models, enriching the definition of domain assets with the constraints concerning the non- functional requirements of a domain. FMO provides the semantic representation of features, relations, dependencies and constraints in one model.

The safety of the ubiquity of wireless medical device network (WMDN) presented by Gehlot and Sloane (2006) can be modeled using NFRs. Other examples or applications of NFRs that can be modeled in feature models are: NFRs to represent the 98

different types of ubiquitous computer devices such as PDAs; and NFRs for monitoring devices and drug dispensers which are used for different functionalities in e-health domain that would require different levels of security access, risk management, software validation and performance.

Kang and Baik (2010) proposed a method for service identification that uses business process models and feature models to bridge the gap between SOAs and SPLs.

Their proposed method deals with a service system composed of services of a SOA that can reflect business processes. Service identification is performed in three steps – invocation: request for service that uses a business process model or a workflow model based on the rules of BPMN; configuration: grouping features containing similar service concepts in the feature model; and specification: representing the attributes of a service in an XML model, that is, the XML schema which has the advantages of extensibility and affluence of representation for reuse, can be reused in all XML-based services. The authors proposed the use of a service bus layer to bridge business process models in

SOAs and feature models in SPLs. While their proposed method presented a conceivable link between SPLs and SOAs, the disadvantage of this approach is that service discovery is not automated as XML schema lacks the considerations of semantics which means that message exchanges, such as for service discovery, requires a mapping between every two different XML schemas before an interaction between the corresponding (Web) services can be set up.

Mahmoud and Gómez (2008) presented an approach that integrates semantic web services principles with service-oriented architecture towards achieving Semantic SOA.

In their approach, a Semantic Web markup language is used to express data structures 99

passed through Web Service interfaces as ontologies to create a distributed knowledge base. The use of ontologies means that it is a lot easier to understand what the service actually can be used for as it provides the means for reasoning (about the web service description) and automatic Web service discovery and execution. The major difference in this approach by Mahmoud and Gómez to that of Kang and Baik (2010), is that with the use of different ontologies by communicating parties, only a mediator (mapping) between the two ontologies needs to be in place, as opposed to needing mapping rules for every two different XML Schemas.

Cardoso (2006) in discussing approaches to developing Semantic Web Services indicated that Semantics can play an important role in all stages of the Web process lifecycle and discussed the different types of semantics that can be used to represent the capabilities, requirements, effects and execution of a Web service. For Semantic Web service annotations the Meteor-S Web Service Annotation Framework (MWSAF) was highlighted as a tool that achieved automatic and semi-automatic annotation of Web services using ontologies.

We saw earlier that BPM has low automation as it lacks the expressivity and logics-based representation to be accessible to machine reasoning, which can be resolved with the use of rules, ontologies or semantic annotations. Milanovi and Gaševi (2009) proposed rBPMN, a Rule-enhanced Business Process Language, which is an integration of BPMN and REWERSE Rule Markup Language (R2ML). Their approach follows proven principles and standards of model-driven engineering and involves integrating the two languages at the level of their metamodels. The authors identified four types of business rules – derivation; integrity; production and reaction, which serve to constraint 100

aspects of the business or control business behaviour. rBPMN was proposed to support the integration of business rules in business process modeling in an effort to provide solutions such as generating more complete service descriptions which are fully based on business vocabulary types; establishing a better connection between process models and business vocabularies; and dynamically updating process model with changes made to business logics. Milanovi, Gaševi, Wagner and Devedži (2009) demonstrated the use of rBPMN in modeling service orchestration. Gaševi and Hatala (2010) proposed a model-driven engineering approach to the development of service-oriented systems based on business process modeling, which integrate business vocabularies and rules in different stages of the development lifecycle.

Pahl (2006) sees ontologies as a natural choice to enhance modeling capabilities and proposed a framework that provides effective support for service architecture modeling on an abstract level. The framework is an integrated, layered, ontology-based, service modeling and transformation framework with benefits such as semantic modeling and reasoning, improved maintainability, and automated generation of a range of different platform-specific implementations. It uses Ontology Definition Metamodel

(ODM) to map between ontologies at the different MDA layers. It uses Web Service

Process Ontology (WSPO) to provide a template for service and service process description, which include semantic information such as pre-conditions attached to each activity defined in the template. Figure 18 gives an overview of MDA and Ontology- based Service Modeling with transformations between the layers and the influence of

ODM for the ontology layers.

101

Figure 18 - Overview of MDA and Ontology-based Service Modeling (Pahl, 2006).

Gaševi et al. (2006) defined a modeling space (MS) as a modeling architecture based on a particular super-metamodel such as RDF(S), MOF and EBNF (Extended Backus–Naur

Form). The authors indicated that a direct mapping cannot be provided between the

Ontology MS and the MOF MS. In presenting mappings between MDA-based language and ontologies, they proposed the use of EBNF as a modeling space to connect Ontology modeling space and the MOF modeling space with XMI (an XML compatible format) used for sharing metadata between MDA layers.

Hepp et al. (2005) suggested that businesses lack a machine readable representation of their process space on a semantic level which is a major obstacle towards mechanization of BPM. They stated that the current BPM is not built on expressive logic based representation techniques, and thus fails at making the whole business process space accessible to intelligent queries and machine reasoning resulting in problems such as low degree of automation in the modeling stage; modeling delay; lack of a clear separation between business goals and implementation details which

102

makes the management of business processes overly complex; process blindness in that managers and other business experts cannot quickly determine whether a specific process can be composed out of existing or query the process space within their organization by logical expressions; and inability to use machine reasoning in order to identify potential side-effects of modifications. They suggested that Semantic Web and Semantic Web

Services (SWS) technology provide suitable large-scale, standardized knowledge representation techniques and proposed a combination of SWS and BPM to yield one consolidated technology called Semantic Business Process Management (SBPM).

Domingue et al. (2008a) have a similar focus and has conducted significant work in the area of semantics for BPM. Their aim is to create SBPM technology, a technological framework constituting BPM enriched with machine readable semantics by employing Semantic Web and Semantic Web Services accompanied by universal reference implementation for mechanized BPM. Figure 19 shows The Semantic Business

Process Management Methodology lifecycle diagram (Domingue et al., 2008b):

Figure 19 - Semantic Business Process Management (Domingue et al., 2008b)

103

Wetzstein et al. (2007) provided a detailed description of SBPMN (Semantic Business

Process Modeling Notation). Some of the functions and features of SBPMN considered to be of significance to this research are discussed below:

• In the Semantic Business Process Modeling Phase, semantically annotated

business process models (SBP models) are produced using tools such as

conventional BPMN. Annotating of the process elements is done by referencing

ontology entities such as organizational ontology, Semantic Web Service (SWS)

ontology and domain ontologies (which describe data). The main benefit of the

semantic annotation is the enablement of automatic semantic-based discovery,

which can be exploited to automatically search for Semantic Web Services.

• In the Implementation phase, the semantic business process model is transformed

to an executable process model, which can be deployed to a process engine for

execution. The transformation step involves finding Semantic Web Services,

which implement the tasks in the process, specifying data flow, and generating a

process mode representation that the process engine understands. The semantic

annotation of the SBP model from the modeling phase enables more automation

in the implementation phase. However some manual refinement may be needed.

According to Wetzstein et al. (2007), the goal of SBPM is to combine BPM with semantic technologies, in particular ontologies and semantic web services (SWS), in order to achieve more automation in the BPM lifecycle. Dimitrov, Simov, Stein,

Konstantinov (2007) proposed that sBPEL - the ontologized version of WS-BPEL, is additionally enriched with extensions from WSMO for goal-oriented discovery, mediation and execution of services. 104

We have seen the many benefits that can be achieved with the use of ontologies which provides a common or standard terminology for representing information and knowledge sharing. However, what needs to be emphasized is that there will be situations that require mediation between differing ontologies. For example, there may be distinct ontologies representing differing conceptualizations of the same domain and ontologies may also differ due to the cost-benefit trade-offs associated with different specifications.

We have seen that the mediator concepts of WSMO allow for mediation between different WSMO elements and also that ODM provides the means for interoperability between different ontologies.

E-HEALTH PROBLEM DOMAIN

The healthcare domain is a very information-intensive, life-impacting and complex domain, which is composed of distributed departments or entities with heterogeneous information systems.

The four main categories of healthcare information systems as identified by

Austin and Boxerman (2003) are: Clinical information systems - support patient care and provide information for use in strategic planning and management. Clinical applications include computerized patient records systems; clinical department systems such as pharmacy and laboratory; and clinical decision-support systems which are systems designed to assist physicians with diagnosis and treatment planning. These applications need to be fully integrated in order to provide useful decision support functions;

105

Management Information systems – include financial information systems, payroll, purchasing and inventory control systems; Strategic decision support systems – assist senior management team in strategic planning, managerial control and performance monitoring; and E-health systems.

E-health is a term used to describe healthcare applications that use Internet technology in the delivery of health services. E-health applications cover a wide range of activities in healthcare organizations including the clinical, management and strategic decision support systems mention earlier. Some goals of e-health include safer patient care; improved efficiency; enhanced quality of care; evidence-based treatment with enhanced decision support to provide timely access to patient’s medical history; and empowerment of consumers and patients (Austin & Boxerman, 2003; Wickramasinghe,

Gupta & Sharma, 2005). Incidences of medical errors and preventable ADEs resulting in injuries or deaths have influenced studies and research into improving healthcare safety

(AHRQ, 2001; Bates, 1995; Kohn, Corrigan & Donaldson, 1999; Raschke et al., 1998;

Long et al., 2010). Whereas ADEs were seen to be injuries resulting from medical intervention related to a drug (Bates et al., 1995), Adverse Drug Reactions (ADRs) are seen by the World Health Organization (WHO, 2008) as "harmful, unintended reactions to medicines that occur at doses normally used for treatment". Bates et al. (1995b) and

Nebeker et al. (2004), distinguish between ADRs and ADEs with ADE seen by Nebeker et al. (2004) to incorporate ADRs and for Bates et al. (1995b), ADE was seen to be more comprehensive and clinically significant than the ADR. This research wishes to further distinguish between ADE and ADR, which are often used interchangeably in literature.

ADRs are considered to be any unexpected reaction to a drug and as such are considered 106

to be mostly unpreventable, so by extension, some ADEs are considered to be unpreventable, since ADR is a subset of ADE as shown by Nebeker et al. (2004). The focus of this research is on reducing incidences of preventable ADEs.

Bates et al. (1995b) in assessing the incidences of ADEs and potential ADEs found that many ADEs were preventable, and that for every preventable ADE there were almost three potential ADEs. Their findings concluded that improvement of systems by which drugs are ordered and administered could prevent many of these ADEs and the costs associated with them. Stephens et al. (2008) conducted a review of patients’ medications which identified discrepancies in the documented versus the actual medications being taken by each patient and concluded that - “a first step in reducing medication errors is for health care workers to be aware of a patient’s medications, allergies and any previously documented ADEs”.

We are of the view that the lack of interoperability and integration between healthcare entities is the main factor contributing to the occurrences of preventable

ADEs. Preventable ADEs can be avoided if the knowledge of allergies or other potentially serious contraindications (from the use of a newly prescribed drug) was made available to the prescriber.

The Healthcare Information and Management Systems Society (HIMSS)9, a not- for-profit organization which is focused on providing global leadership for the optimal use of IT and management systems for the betterment of healthcare (HIMSS, n.d.), defines integration and interoperability as follows:

9 www.himss.org

107

Integration is the arrangement of an organization’s information systems in a way

that allows them to communicate efficiently and effectively and brings together

related parts into a single system.

Interoperability is the ability of health information systems to work together

within and across organizational boundaries in order to advance the effective

delivery of healthcare for individuals and communities.

Patient safety is a major consideration for the implementation of electronic processing

(such as electronic prescribing), to better detect and prevent adverse events. According to

Hale (2007), between 1.5% and 4% of prescriptions are found to contain errors most of which has resulted from miscommunication between providers, pharmacists, and all of the other individuals and technology involved in trying to transfer information between them, that could result in serious patient risk.

The following excerpt from Health Canada, the Canadian government department for health care, provides description of some benefits of e-prescription systems:

“E-prescribing (e-Rx) is a means of streamlining the prescription process by enabling prescriptions to be created, signed and transmitted electronically. There are significant benefits associated with the implementation of e-Rx including the potential to reduce the incidence of medication and dispensing errors caused by illegible prescriptions, a potential decline in adverse drug reactions and the timely transmission of prescription information from practitioner to pharmacist. Health Canada recognizes these benefits and supports the implementation of e-Rx” (Health Canada, 2007). Like any other business

108

domain, healthcare has seen demands for more effective, efficient operations and better quality (of care) at reduced cost. Efficiency in healthcare demands the ability to be able to securely access and share relevant and accurate information in a timely manner. This requires that patients’ medical information be securely stored, accessed and managed requiring interoperability and collaboration between each entity’s e-health systems. There are various factors that can contribute to better interoperability in e-health system.

Among them are – standardized methods for communicating, referencing and sharing of data and an overarching architectural framework. Some key e-health standards are discussed below.

Electronic Health Record (EHR). An EHR facilitates effective communication between healthcare organizations. HIMSS (2010) defines EHR as “a longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data and radiology reports.” The EHR automates and streamlines the clinician's workflow and has the ability to generate a complete record of a clinical patient encounter - as well as supporting other care-related activities directly or indirectly via interface - including evidence-based decision support, quality management, and outcomes reporting (HIMSS,

2010).

Canada Health Infoway (Infoway, 2011a), the organization that fosters the development and adoption of pan-Canadian electronic health information systems in

Canada, anticipates that once completed, “Canada’s EHR will be a secure and comprehensive electronic record of a person's critical health history that can be accessed 109

and shared by authorized health care providers - doctors, nurses, lab technicians across the country” (Infoway, 2011b).

The National Institutes of Health - National Center for Research Resources

(MITRE, 2006) states that EHR is an integration of healthcare data from a collection of systems for a single patient encounter. Key components of EHR include – administrative systems, laboratory systems, radiology system, computerized physician order entry

(CPOE) and pharmacy system. According to MITRE (2006), to create interoperable

EHRs, standards are needed for clinical vocabularies; healthcare message exchanges; and

EHR ontologies. In addition, EHR systems must follow appropriate privacy and security standards.

Health Level 7 (HL7) Messaging Standard. HL7 is a messaging standard that is widely used in messaging across health care applications. That is, it is used to send structured, encoded, data from one application (such as the laboratory system) to another

(such as the EHR). Of the two major versions of HL7 (HL7 v. 2x and HL7 v. 3 RIM), the

HL7 v. 3 Reference Information Model (RIM) has the ability to represent more complex relationships (MITRE, 2006).

SNOMED – CT. Systematized Nomenclature of Medicine – Clinical Terms

(SNOMED – CT) is a controlled medical vocabulary which was developed by the

College of American Pathologists (CAP) for the needs of pathologists in 1965 (MITRE,

2006). It was originally owned by CAP which has since transferred ownership to the

International Health Terminology Standards Development Organisation (IHTSDO)10.

10 http://www.ihtsdo.org/

110

SNOMED CT is considered by Canada Health Infoway as the terminology ‘standard of choice’ for semantic interoperability of EHRs. Standardized clinical terminology is the content backbone of the EHR. Semantic interoperability is enabled by the use of shared clinical terminologies (Infoway, 2008). According to Elevitch (2005) “SNOMED CT’s comprehensive, scientifically validated clinical terminology makes healthcare knowledge more usable and accessible. It is also highly scalable, flexible and facilitates interoperability. SNOMED CT’s core terminology enables a consistent way of capturing, sharing and aggregating health data across specialties and sites of care. To trigger decision support rules, different types of concepts must be linked to each other, such as allergies to drugs, procedures to devices and diseases to contraindications. Decision support built on SNOMED CT enables the development of a more sensitive and sophisticated decision support system.”

Raghupathi and Kesh (2007) in presenting a proposal for interoperable EHR indicated that EHRs must include properties of federation, flexibility, interoperability and openness, to allow for the secure sharing of health data between healthcare entities. In this context, the “federation” property refers to being able to model organizational solutions as federations of services, connected by well-specified contracts that define their service interfaces. Factors such as the high cost of healthcare and the distributed nature of healthcare services have resulted in the adoption of SOA as the conceptual framework for developing distributed interoperable EHR applications in the healthcare domain.

Schrenker (2006) speaks to the issue of safety and interoperability amidst technology changes in the e-health domain. While effecting changes in e-health, 111

measures need to be put in place to ascertain that devices are performing intended functions while maintaining compatibility with other medical devices to provide continued interoperability. Dogdu (2009) identified two main problems in e-health applications - large data stores: accumulation of large amount of data in data stores that are not easily converted into useful information, sometimes stored in databases that are no longer accessed; distributed applications and distributed data stores. He suggests that

Semantic Web technologies provided more extensible and flexible data storage and interoperability options for any information systems including e-health.

Lack of interoperability and integration means health information is fragmented across healthcare information silos. Fragmentation results in problems such as medical errors, inefficiencies and duplications (Brailer, 2005). Interoperability is essential for efficient communication between e-health entities and for integrating business processes.

In order to provide complete and consistent patient care, healthcare entities need to be integrated to function as a collaborative unit, with each entity able to access data from the other areas of care, as needed. Semantic interoperability ensures that e-health systems with conflicting or heterogeneous ontologies can reconcile the differences through ontology mapping (Ryan, 2006), and be able to interoperate. Foreseeable benefits of e- health interoperability include – safer patient care as physicians will be able to access complete patient’s medical history including allergies, medical conditions and medication list, and be better able to make informed, evidence-based decision on patient care; healthcare providers will be able to see all tests ordered by other physicians and in so doing, avoid performing duplicate tests which will contribute to reducing healthcare costs. 112

SUMMARY

Often times the systems developed by an organization have a high degree of commonality. SPLE emphasizes planned reuse of assets by extracting the commonalities and variations in a specific product line or domain to develop reusable core assets that can be propagated across the related systems in the domain. Some benefits from this approach are increased level of automation, reduced cost, quicker development and maintenance times and higher quality software products. Feature models are very commonly used to model the problem domain or problem space by representing the commonalities and variability of the product line.

SPLs are described as “closed” because of the focus on a specific domain or product line as opposed to service-oriented architecture (SOA) which is “grounded on the idea of ‘open’ integration of business processes by means of shared services” (Gaševi,

2009-2010) and as such is seen as being “opened”. SOA uses services as a reuse component to support the rapid development of low-cost, interoperable, distributed applications. The most recognizable application of SOA is Web services which have been shown to have automation limitations. This limitation is addressed with Semantic web services, which is the semantic annotation of Web services making them machine readable to facilitate automatic discovery.

Nickul et al. (2007) stated that “one perceived value of SOA is that it provides a powerful framework for matching needs and capabilities and for combining capabilities to address those needs by leveraging other capabilities”. The integration of SOA and

BPM technologies provide new opportunities for making integrated distributed systems

113

more flexible and adaptable to business process changes while bridging the gap between

IT and business.

While SPL and SOA differ in their respective scopes, they share similarities in their approach for reuse. An SOPL could leverage the service-based features of SOA in a specific domain. That is, while SOA focuses on the design approach and concepts that will realise a service-based approach to system development to enable characteristics such as adaptability and loose coupling, SPL systematically captures and exploit the commonality of a set of related systems managing the variability for mass customization.

We have seen that MDA can be used to model SPLs and the use of SoaML with SOAs. A model driven service-oriented SPL adds a level of abstraction away from the software products or services. The use of MDA brings a level of automation, which reduces development and maintenance costs while improving agility. Ontology as conceptualizations of domains will be the glue to bind all concepts and technologies together.

Subsequent chapters will attempt to achieve a synergy of the main concepts and technologies towards defining a methodology which can be applied to the e-health domain to improve interoperability and in so doing reduce incidences of ADEs.

114

CHAPTER 3

METHODOLOGY

Interoperability is the key to improving collaboration and communication between healthcare entities, integrating business processes and enhancing patient safety by reducing incidences of ADEs.

We believe that the occurrences of ADEs can be reduced through integration and better management of prescribed drugs in relation to patients’ complete medical record, which is within the scope of an electronic prescription (e-prescription) information systems domain, and which requires efficient communication and collaboration between e-prescription system and other e-health systems. The focus of this research is therefore to propose a design methodology for the e-health domain that can be applied to the e- prescription (sub-) domain for improved interoperability, integration and communication, towards reducing incidences of ADEs.

The e-health domain is comprised of families of related systems or product lines which share common features such as EHR but which differ on the types of service provided, with each system focused on a specialized area of patient care. Similarly, specialized healthcare areas or e-health sub-domains such as e-prescription, also show variability, with functions differing based on the implementation environment. For example, an e-prescription system implemented in a hospital setting could contain features for processing emergency care prescriptions which are not present in a private

115

physician’s office. As we saw in chapter 2, e-health also presents as a distributed domain.

An SOPL framework is considered to be best suited for representing the e-health domain as families of distributed services in which business processes can be better aligned with

IT.

This research investigated the alignment of several emerging technologies towards achieving a synergy that could be applied to e-health. . The approach sought to use cutting edge technology that would:

• Allow for relative ease of integrating related systems

• Facilitate collaboration between systems to allow for cross referencing, for

example: to be able to query a patient’s medical history against current

medication list and decision support systems

• Facilitate interoperability. Achieving interoperability in the e-health

domain means that services need to be able to communicate and

collaborate regardless of the location of e-health system and any

heterogeneity factors, such as - differences in the language or ontology

used by each system.

From the reviewed literature we identified some emerging technologies as components in a possible solution for addressing ADEs in healthcare:

Semantic Web services (SWS) offered promises of interoperability and tasks automation such as service discovery, composition and invocation thereby enabling (electronic-) business process automation. SAWSDL facilitates ontology mapping to allow for semantic interoperability, that is, ensure that systems with different domain models or ontologies can communicate; 116

SOPL, as we saw earlier, was selected as the framework for representing the e-health domain as distributed families of conceptual services; and

Model-driven approach was taken for improved system development.

What emerged was a synergy of five main concepts and technologies – SPL,

SOA, MDD, BPM and Semantic Web Technology, which defined our proposed methodology – Feature-Oriented Domain Analysis (approach) for Semantic Web services (FODA4SWS). We propose that this methodology can be used to resolve challenges of interoperability, integration and communication in distributed e-health systems, and by extension, address the issues of preventable ADEs for safer patient care.

FODA4SWS Methodology Overview

On the premise established by Kang et al. (1990) that “the feature model captures the functionalities or capabilities of applications in a domain, or the user-visible

‘services’ provided by the applications in the domain”, the feature model is seen as a cohesion point for SPL and SOA, with the core assets of the product line being reusable, unique services obtained from customization or valid composition of the features in the variability feature model. The feature model represents the commonality and variability in the domain as user-visible conceptual services that can be clearly mapped or configured into valid (Semantic Web) services.

Our approach adopts the perspectives of Cohen and Krut (2010), Smith (2009),

Mohabbati et al. (2009) and others on an integrated SOPL – the integrated framework encourages reuse of core assets and functionalities; SPLs address a market segment, 117

support systematic or planned reuse with the use of a production plan to facilitate rapid development of new products from the core assets; SOA implements business processes within an enterprise and offers a prescribed standard for constructing each product in the product line, exposing the services for service invocation. Strategically planned reuse, a strategy employed in SPLs, can be exploited to achieve benefits such as increased productivity, decreased development and maintenance costs, improved time to market, higher reliability, and a competitive advantage.

The exposed services enable interoperability by providing the ability to connect applications across platforms, languages, ontologies, standards and geographic locations.

SAWSDL provides the mechanism to add semantic annotations to WSDL components of services (Verma & Sheth, 2007) and also provides mappings to domain ontologies or standards (such as HL7 or SNOMED-CT) thereby enabling semantic interoperability between e-health systems.

A combination of top-down and bottom-up approach, as described by Kemsley

(2008), is proposed for integrating business process management with SOPLs. We take a business-focused approach, as opposed to technology-focused, with the business goals and objectives used to direct the identification and definition of business processes, identification of the reusable services needed for realizing the business processes, alignment of the order of service development with business goals and identification of technology required to realize the architecture and achieve the overall business goals.

MDD, as discussed in Chapter 2, can play a key role in automation. While MDD is used to add abstraction to aspects of a product line, SPLE provides a well-defined application scope for the development and selection of models. 118

This approach takes the model-based perspective to SPL as expressed by Gröner, et al. (2011), which sees an SPL as consisting of problem space models (usually feature models); solution space models or model templates to be modeled using BPMN, which are used to reflect the variability of the domain and provide a clear visual mapping to feature models and; mapping models which maps between the features selected in the problem space models and the solution space models. We propose the use of ontologies to annotate the feature model which will then be transformed via mapping models into ontology-enriched solution space models. Ontologies are incorporated to add intelligence to business processes for automatic service discovery and interoperability. We also consider the use of ontologies to represent NFRs, for example: in feature models – to represent information such as name, description, constraints and relations between features (obtained from a domain ontology), and as traceability links between models.

An iterative and incremental process is proposed for defining the feature models and identifying business processes and the services required to satisfy business processes and

MDA model transformation principles are employed to perform multiple model transformations. Figure 20 shows the integration of MDA with Domain Engineering processes of SPLE.

119

Figure 20 - MDA approach to FODA4SWS (Asadi et al., 2009 - modified)

By MDA specifications there are three modeling layers each with a distinct function:

CIM (computational independent model) the purpose of which is to capture the 120

requirements, concepts and properties of a domain; PIM (platform independent model) is the layer which describes the operation of the system as models independent of any platform; PSM (platform specific model) is the layer which has models that rely on specific platforms with a focus on interoperability. An implementation model describes the actual solution or physical system that satisfies what is specified in the PSM.

Domain Engineering. We will now look at the MDA transformations performed in the Domain Engineering phase of SPLE.

CIM to PIM Transformation. The CIM, domain model or requirements specifications model, is the primary input into the Domain Analysis process which follows the FODA methodology to produce the problem space variability feature model.

The product line scope needs to be defined prior to performing feature modeling (a function of FODA Context Analysis). Scoping of the domain needs to consider: existing business functions; domain resources and constraints; the relationships between the processes in the domain under review and elements external to the domain; recent developments or plans for future technical developments; variability of the usages and the contexts of use such as environmental differences. To achieve reusability in the product line, the scope needs to evaluate the commonality of the domain in existing applications, potential uses and benefits of the domain products and feasibility of constructing domain products. After agreeing on the scope, the next step is to garner an understanding of the domain or performing FODA Domain Modeling. Activities include - capturing, refining and structuring user requirements; capturing knowledge from domain experts; capturing knowledge from pre-existing legacy systems and documentations such as business 121

process diagrams which provide detailed graphical representations of the system; validation and verification by domain experts. By nature of the need to manually analyze user requirements (and other domain information) in order to create the feature model, the ‘transformation’ at this level (from CIM or requirements document to feature model) is a manually executed process.

One focus of a feature-oriented approach is to identify variability that can cause differences among applications in a domain. A feature model captures the domain knowledge in the form of distinguishable reusable software assets, which, in a SOPL paradigm are exposed as reusable ‘services’ from which business processes can be composed, and a service represents a business functionality either in whole or in part.

The final result of this process is a variability feature model that represents the problem domain with semantic annotations from mapping features to concepts in the domain ontologies.

PIM to PIM Transformation. From an MDA perspective, the transformation at the PIM abstraction level involves feature model as the source and business process model as the target model of the transformation. BPMN, the standard modeling language, is used to model the business process. Our proposed approach incorporates ontologies in the transformations to add expressivity and traceability between the models. This transformation proposed is similar to the work of Montero et al. which used Atlas Transformation Language, the feature model metamodel as the source and Eclipse SOA Tool Platform BPMN metamodel as the target metamodel for transformation from feature model to business process model. Our proposed approach

122

differs in the incorporation of domain ontology in the feature model which is then transformed to a semantically annotated business process model.

From a SPLE perspective, the Business Process Service Analysis (BPSA) process integrates business process management activities in the SOPL. It incorporates aspects of

FODA Architecture Modeling which is responsible for the creation of the software architectures used to implement solutions for the problems represented in the problem space feature model.

BPSA inputs the semantically annotated feature model to provide architectural or design reference models from which the detailed designs will be derived during the

Domain Design process, and services discovered in the Domain Implementation process.

Business process model templates that represent the solution space and reflect the variability of the domain are developed in this process. As stated by Hatala, Mohabbati,

Asadi, Boškovi and Gaševi (2011), the business process model template contains the union of the business processes of all valid applications and can be modeled by process- oriented modeling languages such as BPMN.

It is therefore here (in BPSA) that we identify the business processes required to achieve all the organization’s goals or objectives, the associated conceptual services needed to perform the business processes as well as identify the interoperability and integration needs. The feature model developed in the previous process is referenced for available conceptual services required for business functions. In the event that a required service is not described in the feature model, BPSA references the concepts from domain ontologies to derive the required service and updates the feature model. This allows for incorporating changes in user requirements or business goals, while ensuring traceability 123

of the solution space models back to the feature model. As noted before, the model template at this stage contains features and activities for all possible business process.

To connect the feature model and the business process model template, we define a mapping between their elements, i.e., mappings between features and activities (Hatala et al., 2011). The activities in the business process model template have a one-to-one mapping of the features in the variability feature model. Mapping models that define the relation between feature models and solution space models are also defined during the

BPSA process.

PIM to PSM Transformation. The Business Process Realization process depicted in Figure 20 takes as input the mappings between the feature models and business process models for implementing the business process model template and discovery of services, during the domain implementation process. Services are discovered for each business process activity in the solution space. According to Hatala et al (2011)

‘the implementation process of the business process model template in the domain engineering lifecycle focuses mainly on generation of queries for discovering services, which offer operations implementing each activity defined in model template.’

For the transformation between the two abstraction levels (PIM to PSM), WSMO framework was selected due to merits such as its expressiveness and being a discovery engine that allows for dynamic discovery, mediation and invocation of web services.

WSMO is comprised of WSML (Web Service Modeling Language) a formal language used for describing the WSMO based services, WSMX (Web Service Execution

Environment) a reference implementation of WSMO which facilitates the discovery, invocation, composition, and monitoring of Web services described in WSMO and 124

WSMT (Web Service Modeling Toolkit) which is integrated with the WSMX Execution

Environment and used as a text editor for updating text. The WSMO framework is sufficiently described by Rusk (2009). As we saw in Chapter 2, business process model notation (BPMN) has an automatic mapping to an executable and interpretable language of BPM Systems, such as BPEL. Therefore the implementation and execution of a business process model will automatically invoke the required services from the

ServiceInterfaces.

The WSMO framework includes a SAWSDL editor. SAWSDL provides the means for adding semantic annotations to web services, for mapping data between different Web Services and for mapping between different ontologies, for example,

SAWSDL will map between an EHR-Management Web service and a Disease-

Management Web service. SAWSDL also provides mapping to standard ontologies and between different ontologies.

A mapping between ontologies HL7 RIM messages and SNOMED-CT will give access to information such as blood pressure readings. Ryan (2006) in discussing the mapping between theses two ontologies (HL7 RIM and SNOMED-CT), indicated that for semantic interoperability in healthcare these two ontologies need to be able to work together which requires a mapping from one ontology to the other. The author went on to state that since SNOMED-CT models are actual clinical constructs, HL7 models will be based on the existing SNOMED-CT models (Ryan, 2006).

Application Engineering. As we saw in Chapter 2, the two SPLE development life cycles – domain engineering and application engineering are performed in parallel, and 125

as stated by Czarnecki (2004), both processes feed on each other. Although the focus of our proposed methodology is on Domain Engineering, we need to take a look at

Application Engineering for the actual product derivation.

During the application engineering lifecycle, the variability model defined in domain engineering will be managed to produce concrete realizations according to user requirements (Hatala et al., 2011). User requirements will cause the exclusion of some optional features from feature model which will in turn result in the removal of the associated business process model template activities and the associated services. More significantly, user requirements will determine what variable or optional features and associated process activities and services are selected for inclusion in a final product configuration.

TOOL SUPPORT

The initial step of identifying the characteristics of a domain requires considerable human intervention for interpreting user requirements, documentations, and domain experts’ knowledge. For representing domain characteristics in a feature model, there are a number of feature modeling tools available, such as: XFeature, FAMA and FeaturePlugin which are discussed next followed by a discussion on transformation tools.

FeaturePlugin - a Feature Modeling Plug-In (FMP) developed by Antkiewicz and

Czarnecki (2004), extends the original feature modeling from FODA with feature and group cardinalities, feature attributes, feature diagram references, and recording of annotations such as binding times and feature priorities in a user-extensible metamodel. 126

FeaturePlugin is an Eclipse plug-in tool with functionalities to support modeling of large feature diagrams, generating a model which can easily view and edit feature diagrams, exportation of models and configurations to XML documents and specifying constraints.

However, constraint checking is not fully developed and feature cardinalities are not supported and are untested in the current version - fmp.0.7.0. The .fmp file generated is

Ecore compatible and can be read and navigated directly by ATL.

XFeature developed by Rohlik and Pasetti (2004) is an XML-based feature modeling tool which is also implemented as an Eclipse plug–in. XFeature allows users to define their own feature meta-model. XFeature supports the modeling of product families and applications instantiated from them.

FAMA (FeAture Model Analyser) is a framework for the automated analysis of feature models which was developer by Benavides, Segura, Trinidad and Ruíz-Cortés

(2007). FAMA is another Eclipse plug-in which has been implemented as a complete tool for the edition and analysis of feature models. FAMA supports cardinality based feature modeling (including traditional feature models such as FODA and FeatuRSEB), export and import from XML and XMI and analysis operations on feature models.

Transformation tools

Atlas Transformation Language (ATL) is an Eclipse Plug-in that is often used to perform model-to-model transformations with the use of transformation rules to map from a source to a target metamodel. For the proposed approach this would require multiple transformations, the first of which is a transformation from feature model metamodel to

BPMN metamodel. 127

FeatureMapper is a tool approach to combine SPLE and model driven software development which was developed by Heidenreich, Kopcsek and Wende (2008).

FeatureMapper is an Eclipse-based tool that allows for mapping features from feature models to their realization as solution artefacts in the solution space, expressed by means of an EMF/Ecore-based language. This mapping allow for the automatic derivation of a concrete product based on a given variant configuration. FeatureMapper tool aims to achieve well-formed-ness of SPLs, or the creation of correct products of an SPL, by ensuring the correctness of all participating models of an SPL such as feature models, mapping models, and solution-space models. The tool supports both automatic mappings and manual mappings and offers various means for defining views on the mappings.

FeatureMapper tool provides the capability of mapping the problem space source (feature model) to target models (such as business process model and service model) in the solution space.

Modelio is an available tool for transforming business process model to SoaML model. It is an integrated UML modeling tool that supports the majority of UML diagrams and offers mapping between SoaML and BPMN. Modelio is available in two

Editions, the Enterprise Edition and the Free Edition, each designed to meet different needs. (Modeliosoft, 2009)

WSMO Studio with BPMO Modeler was selected as the transformation tool that could incorporate ontologies in the transformation of business process model to semantic web services. WSMO Studio is an integrated Semantic Web Service and Semantic

Business Process modeling environment for the WSMO framework, which is Eclipse- based (Dimitrov, Simov, Momtchev & Konstantinov, 2007). Its functionality includes 128

core components to create and validate WSMO models and import and export formats such as WSML, XML and OWL-DL. WSMO Studio defines three perspectives: WSMO;

Repository and SAWSDL. The WSMO Perspective groups together functionality related to creating descriptions of WSMO elements (ontologies, goals, services and mediators) in

WSML formats which can be exported to an XML format. The SAWSDL editor allows for adding semantic annotations to the WSDL documents of individual Web services, mapping data between different Web Services as well as ontology mapping. Use of the drag and drop features facilitates attaching semantic annotations such as concepts, instances, WSMO goals, axioms and mediators to specific BPMO elements.

The BPMO Palette provides the basic building blocks of a business process

model. Each component of the Palette roughly corresponds to an element in the business

process model, in accordance with the BPMN notation. Yan, Cimpian, Zaremba and

Mazzara (2007) described the BPMO Modeler as an extension of WSMO with a

fundamental element BPMOElement which inherits all description properties. The four

BPMO elements are Ontology, BusinessProcess, BusinessGoal and Mediator seen below:

Figure 21 - BPMO Architecture (adopted from Yan et al. 2007)

129

CHAPTER 4

RESULTS and ANALYSIS

This chapter will use an e-prescription case study to illustrate the methodology presented in Chapter 3. We will illustrate how the domain is represented as an SOPL and discuss how the methodology is perceived to improve interoperability and reduce ADEs.

E-PRESCRIPTION (e-Rx) CASE STUDY

There are significant benefits that can be gained from the adoption of an e-Rx approach over the traditional paper-based approach. The move towards e-Rx by countries worldwide is driven by the need to address life-threatening events resulting from medication error such as drug-to-drug, drug-to-allergy and drug-to-illness and other interactions (Health Canada, 2007; Medicare Australia, 2010; CMS, n.d.).

As a subset of the e-health domain, an e-Rx customization will share common or mandatory e-health features, such as features related to accessing and updating a patient’s medical record or EHR, with other applications within the domain. However, features such as ‘Prescribing drugs’ is unique to this sub-domain. Within the e-Rx domain, there are mandatory features and variable features which represent the differences in functionalities for different e-Rx implementations. The e-Rx domain needs to be structured for strategic reuse which means defining it as a product line and applying

130

SPLE principles, starting with identifying the common and variable features from which reusable services can be derived.

In this case study the assumption is made that there is an existing system with documentations (such as: requirements specification, user manual, business process) that can be used for defining the domain scope. In the context of an e-Rx domain, the two main roles are Physician: represents all medical professionals authorized to write prescriptions; and Pharmacist: represents someone legally authorized to dispense drugs.

Feature modeling is performed to identify the variability and commonalities of the domain as reusable services represented in a feature model. For this illustration, we have a hypothetical e-Rx system with the ability to select drugs, query contraindications, process prescriptions based on classification (standard, priority or emergency), query insurance coverage to determine affordability of drug before prescribing and also the ability to cancel an existing prescription, place a prescription on hold (pending for example the results of a lab tests). A verified prescription is one which is available for dispensing by a pharmacist.

For our hypothetical e-Rx domain, we will first perform variability modeling to identify common and variable features that can be represented in a feature model.

Two mandatory features were identified - Classification and State. As we saw earlier,

Classification is used to determine how the prescription is processed with ‘standard’ seen as the default classification that would appear in the implementations found in private offices. Priority or Emergency are the two other variations of this feature that could be found in implementations in a hospital or other critical care setting, with emergency prescriptions handled differently from a priority classified prescription. Variable features 131

include – Insurance coverage, which is not a required feature for implementations where health systems are totally publicly funded; SelectDrug and Contraindications are seen as variable features (albeit very unlikely in a real-world scenario), and would not be included in e-Rx implementations that are focused on reviewing or cancelling existing prescriptions. We would also need to define the dependency relationship between optional features - SelectDrug and Contraindications, so that if SelectDrug is selected in a configuration, Contraindication will also be selected.

After performing requirements analysis and variability modeling on the domain, the resulting feature model is shown in Figure 22. From the representation of the feature model, we can see that there are three ‘and’ feature associated with the e-Rx product line

– AssessPatient, Prescribe and UpdateEHR. Prescribe also has two ‘mandatory’, ‘and’ features associated with it, namely: Classification and State and three optional features –

SelectDrug, Contraindications and Insurance which may or may not be in a given implementation. Treatment Option has a mandatory feature in Prescription and an optional feature labelled OTHER (Lab Test/Therapy/Surgery/Observation). OTHER is not a particular treatment option but is used to represent the four named optional features, to make the diagram easier to read.

UpdateEHR has four ‘or’ features which means at least one of the four, must be selected.

Diagnose is an ‘optional’ feature associated with AssessPatient. A diagnosis may not be performed on a patient with a previously diagnosed or pre-existing health condition who is already on a pre-determined drug treatment, and who visits a doctor for a repeat prescription to continue the drug treatment. Alternative features include Standard,

Priority and Emergency associated with the Prescribe Classification feature and 132

Comprehensive, Co-Payment and No Coverage associated with Prescribe.Insurance feature.

Figure 22 - e-Rx Feature Model (Problem Space Model)

BPMN is used to model the solution space of the e-Rx SOPL as business process model templates containing all valid configurations or applications for the SOPL. Business process service analysis is the phase in the methodology where the need for integration and interoperability is clearly identified with the identification of the collaborative services, that is, service in compositions. Service composition is where we identify the

133

service needed to execute business processes. Service composition is a SOA feature which requires efficient communication in order to perform business functions and in order for business processes to interoperate. SAWSDL describes the services with the relevant (domain) ontologies to allow for enhanced interoperability.

Figure 23 shows the business process model template for the Prescribe feature which is part of the e-Rx SOPL.

Figure 23 – e-Rx BPMN (Solution Space Model Template)

The activities in the business process model template map to the features in the variability feature model, that is, each feature will have an associated business process activity.

Labels are used to give a clearer illustration of the mapping relationships between these

134

two models. Mappings between some of the features from the problem space feature model and associated activities in the solution space business process model template, are shown in:

Table 2 - Mappings between features and business process model template activities

Feature Activity

7: SelectDrug 2,7 : SelectDrug

8: Contraindications 2,8 : Query Contraindications

9: Classification 2,9 : Classify Prescription

10: Insurance 2,10: Insurance Coverage

11: State 2,11: Confirm Action

24: Comprehensive 2,10,24 Comprehensive;

28: Verify 2,11,28: Verify

As seen with Gröner et al. (2011), variability of the domain needs to be reflected in both the problem space feature model and the solution space model (or business process model template). Using the mappings between the feature models and business process models, we can implement the business process model template and perform service discovery for each activity in the business process model. Optional features in feature model are represented as processes in the business process model template on which a conditional or Boolean processing can be used to select or not select a process depending on the mapping features selected in the feature model.

135

We will provide two scenarios to illustrate how user requirements impact the implemented e-Rx.

Scenario 1

User Requirements: An e-Rx system to service a private physician’s office, with capability to generate e-Rxs. Insurance coverage capability is not required.

Result:

The Insurance feature is removed from the feature model along with corresponding business process model template activities and services.

Mandatory features – Classification and State and Optional features – SelectDrug and

Contraindications are selected along with their corresponding business process activities which are included in the e-Rx implementation and which results in the service discovery for associated services of each selected activity. Note that SelectDrug provides the functionality to prescribe drugs, however this feature requires Contraindications which provides the functionality of QueryContraindications process activity.

‘SelectDrug requires Contraindications’, highlights a dependency and collaboration between these two business processes activities.

QueryContraindications activity could, for instance, invoke services like – EHR-

MedicationList and EHR-Allergies to retrieve a patient’s medication list and allergies respectively and a Decision-Support Web services could, for instance, be annotated with aspects of the SNOMED-CT ontology for determining potential ADEs. In this scenario,

SAWSDL provides a mapping between HL7 RIM and standard ontologies like

SNOMED-CT in order to transmit messages with relevant medical content. SAWSDL 136

also provides the mechanism for mapping between ontologies that represent same or different domains. For the above interactions, each selected drug is queried against patient’s medical record (EHR) for – existing medication list, allergies and existing medical conditions, in order to determine if any ADE exists with the newly prescribed drug. Interoperability between the services such as EHR-Allergies, EHR-MedicationList and Decision-Support enables the collaboration and integration required to effectively perform the QueryContraindications activity.

(NB. If a drug allergy existed and the EHR-Allergies service was not accessible, the result would be an ordered prescription with the potential to cause ADE.)

Scenario 2

User Requirements: An e-Rx system with the ability to query and cancel existing prescription. This system will be used by a support staff with no authority to prescribe drugs.

Result:

This implementation needs to restrict the prescribing functionality therefore features

SelectDrug and Contraindications will be excluded from the feature model. Only the two mandatory features – Classification and State will be included. The result is a business process model template with only these two Prescribe corresponding activities selected and for which services can be discovered.

The e-Rx implementation in this scenario can query previous prescriptions based on some combination of search criteria attributes which could include – prescribed drugs, 137

specific medical conditions and patient identifier. This e-Rx implementation can be used to identify patients affected by a recent drug recall due to research findings of serious potential ADE. This type of query requires integrating and cross referencing the relevant business processes to identify patients, contact information and other relevant addition information in order to stop the administration of the recalled drug and order any relevant treatment. This is made possible with interoperability.

Scenarios 1 and 2 were used to illustrate two unique configurations or implementations of e-Rx that can be realized from the feature model in Figure 22. In Both scenarios we sought to illustrate the steps involved in the domain engineering phase (of SPLE) as it relates to the three models produced – the problem space feature model, solution space business process model and mappings between the feature model and business process model. We also sought to illustrate that variability of the domain is represented in both the problem space and solution space models and the impact of user requirements on the actual implementation. We then discuss how interoperability or the lack of interoperability affects the results.

The incorporation of ontologies, is an essential part of the proposed methodology, however this is not illustrated in the above models. Ontologies provide a common understanding of a given domain, which enables communication. Ontologies add meaning to services and data that enable applications to understand and communicate on a machine-to-machine level which aids interoperability. The use of ontologies in feature modeling will require tool support that imports or incorporates ontology structure into the 138

feature model, which could possibly be implemented in a drag-and-drop approach to link the ontology concepts to the features or services in the feature model. Error! Reference source not found. Figure 24 below gives a representation of an e-Rx domain ontology that could be incorporated in a feature model. This ontology shows that e-Rx includes drug(s) and shows relationships between physician, patient and e-patient record or EHR.

The use of ontologies such as SNOMED-CT, e-prescription related or drug chemistry ontologies, adds meaning to data, models, services and other elements which adds a greater degree of flexibility and interoperability to the product line, allowing for machine-to-machine interactions with different ontologies, and introduction of new information and non-functional requirements such as security features. As we have stated throughout this paper, ontologies also enables mapping and better traceability between models.

Figure 24 - e-Rx Ontology (adopted from Puustjärvi & Puustjärvi, 2006)

139

EVALUATION

This paper sought to emphasize a business-driven feature-oriented approach to domain analysis for the development of semantically interoperable Web services. The e-health domain and more specifically e-Rx, was used to illustrate the approach. Illustrating the feasibility of the proposed approach to improve aspects such as interoperability and efficiency in this complex and distributed domain with life-threatening consequences, was thought to add more credence to the applicability of the approach in other domains.

The approach advocated that a feature-oriented (approach to) domain analysis is an essential step to understanding and defining domain characteristics. A comprehensive domain analysis is thought to facilitate better understanding of the domain, which increases the chances of developing successful systems, that is, systems that reflect the domains features and satisfy business goals.

We sought to exploit the benefits of SOA and SPL in the combined SOPL, with the use of ontologies to improve traceability between models. Semantic Web services bring more automation to service advertisement, discovery, selection, composition, and execution of business processes, allowing for better communication and collaboration between distributed systems.

We performed scoping and analysis of the domain in order to capture commonalities and variations as features or user visible reusable services. Feature models in the proposed SOPL are seen to represent the conceptual Web services annotated with domain ontology, which allows for ontology-based reasoning; bidirectional mappings and transformations between models (and ontologies) at different abstraction layers; and

140

ultimately provide the information to support the automated realization of concrete

Semantic Web services. The proposed approach allows for the introduction of new business processes and services, changes to feature models, alignment of services with business process while maintaining traceability between models.

From the SOA perspective, great importance is placed on identifying (and prioritizing) the business processes for development and on identifying services required to perform the business functions. This approach is taken because we think that the business operations or goals need to be the driving force behind the development of information systems. Some features of SOA that are exploited in this design are – services to wrap existing application thereby taking advantage of prior investments, services can be selected and composed dynamically at runtime, thus enabling system flexibility, adaptability and automation.

Ontologies are incorporated into the models at different abstraction levels, such as in the feature model, business process model and web service model. The aim for using ontologies is for to improve communication, service discovery, composition and invocation, with the anticipated outcome of improved automation and interoperability of business processes. The injection of ontologies also means that tools supporting the different abstraction levels need to facilitate linking ontology concepts to the model elements, for example to link the domain ontology concepts to the features in the feature model.

We have discussed a range of anticipated benefits that could be realized with the proposed approach. However we would like to acknowledge that this is not proof of concept or an approach void of potential difficulties. We envision that adopting an SOPL 141

architecture would require considerable work in reuse planning and human intervention to perform tasks such as business process re-engineering to allow for identifying and developing autonomous services for reuse and this presents a potential difficulty. SOPLs are also likely to be more complex and potentially less manageable than traditional software design as it includes the features (user visible services), their relations and the different product variants that can be formed from reuse. Additionally, the number of potential product variants increases as the number of features increase. As such, scoping of an SOPL is potentially more problematic that scoping a typical SPL.

The initial cost of an SOPL may also be an area that prevents the adoption of this approach. There is an anticipated learning curve to adapt to this new way of thinking especially for business analysts and developers. Also, for any system to be successful the users and other stakeholders must accept and use it.

The use of ontology in the layered models in this approach is potentially problematic, requiring considerable work at standardizing domains’ vocabularies and terminologies and in aligning ontology concepts with model elements for better knowledge sharing and reuse potential. We anticipate the in order to incorporate ontologies we would need to have tool support. For example, all three feature modeling tools mentioned earlier (FeaturePlugin, FAMA and FeatureMapper) would need to be extended to facilitate linking ontology concepts to features in the feature model. Security and the management of access to data and services will be more problematic in an SOPL than in traditional systems or in an SPL which is inherently closed and this also an area of concern.The main contributions of the methodology:

142

• The methodology is based on an integrated ontology-focused, model-driven

service-oriented product line (SOPL) framework which is reuse-focused with

benefits such as reduced development cost, improved quality and reduced TTM

• SOPL framework shows promise for longevity with service-based architecture

offering an agile, flexible, adaptable framework which can evolve as the domain

evolves. An agile, adaptable and flexible framework is considered to be a suitable

match for the e-health domain

• Ontology is used to describe elements at all levels of the MDA , which enhances

automation to the development, mapping between models, traceability between

models

• MDA approach offers flexibility in being able to separate business logics from the

implementation platform, and in so doing, allows for changes to the underlying

platform without affecting existing applications

• a simplified development process is offered through the model-driven

development that transforms the conceptual Web services identified in feature

models into SWSs – concrete software product realizations

• The integration and interoperability needs of the domain are identified in the

business process analysis phase. This phase is therefore considered to be of

significant importance in this methodology

Interoperability and integration occurs primarily business process modeling stage with interoperability between business process models; SAWSDL facilitates semantic interoperability through ontology mappings; Services promote integration with the ability

143

to connect applications across geographical boundaries and technology conflicts such as different languages or ontologies.

RELATED WORK

We will look at related work from two perspectives – i) methodology design and ii) e- health related perspective.

Design-related

Like Rusk (2009), this approach selected the FeaturePlugin feature modeling tool for creating the feature model used to illustrate the methodology. Rusk advocated adopting the feature model to represent Web services in a SPL and using the Web Service

Modeling Ontology (WSMO) to encode SPL configurations. Rusk’s work performed a direct transformation from feature model to WSMO model using ATL transformation rules to map from a FMP metamodel to a WSMO metamodel. Our approach proposes a multi-phased transformation, the first of which is a transformation from a feature model to a BPMN model which would require transformation rules to map from a feature model metamodel to a BPMN metamodel.

Montero et al. (2008) used FAMA as the feature modeling tool in the transformation of feature model to BPMN model which is closer to the desired outcome of our first transformation. The FeatureMapper tool by Heidenreich et al. (2008) provides the capability of mapping the problem space source feature model to target models (such as business process model or service model) in the solution space. 144

Brambilla et al. (2007) proposed a model driven design and development approach for semantic Web service applications and performs a semiautomatic extraction of WSMO descriptions of Web services from BPMN models, which bears similarities to a part or our proposed approach. Another significant difference between our approach and Brambilla et al. is the starting model (or process) that each approach is based on.

Their approach is based on a business process model whereas for us, the emphasis is on the domain analysis process for defining feature model.

E-health related

MyRxPad (Nelson, Zeng & Kilbourne, 2009) is a prototype application developed at the

National Library of Medicine that is based on a practitioner-patient collaborative approach to e-prescribing. The patient is required to maintain a personal medication list which is used by the prescriber as the single reliable source for well-informed and safe medication prescribing decisions. The MyRxPad application checks for overdose at the ingredient level and issues alerts. With MyRxPad, the onus is on the patient to maintain the medication list which is seen as a potential drawback. However, it can also be seen as a benefit as this approach allows for addition of non-prescription or over-the-counter

(OTC) medications which may not be otherwise recorded in a patient’s medication list, allowing for more accurate result when querying at the ingredients level. Our approach uses ontologies and semantic web technology to enable collaboration between information systems such that a prescription entered by a prescriber is accessible

(globally) to all healthcare systems in the e-health network. Our SOPL framework also

145

has the flexibility to be extended, for example, with a patient-managed medication service to enable patient inputs or other patient-driven interactions.

COCOON Glue (Della Valle & Cerizza, 2005) is a WSMO complaint Semantic

Web Service execution environment that aims at offering an efficient system for the management of the Web Services. WSMO is used to facilitate automation of Web service tasks for seamless integration of e-health applications in COCOON Glue project, which is similar to our FODA4SWS approach. WSMO includes facilities for publishing semantic descriptions of the available Web Services, so that a discovery engine, integrated within COCOON Glue, can operate on these descriptions in order to automatically select the most suitable Web Service for a specific task. Web service discovery allows for identifying services to assist in decision support as well as identifying relevant patient-related information to be incorporated in the decision process.

Artemis Project (Dogac, Laleci, Kirbas, Kabak, Sinir & Yildiz, 2003) provides a

P2P (Peer-to-Peer) interoperability platform that exploits ontologies based on the domain knowledge exposed by the healthcare information standards through standard bodies like

HL7. The healthcare institutes define their own ontologies based on the existing healthcare information standards. The mediator component of the system uses the Service

Functionality and Service Message ontologies as references to reconcile and resolve the semantic differences between two healthcare institutes. The P2P framework provides for scalability and automated discovery. This differs from our approach where the Internet and SAWSDL essential acts as the ‘interoperability platform’, performing mappings between ontologies and resolving conflicts between ontologies. The use of SAWSDL in

146

our approach raises questions on mapping agility, that is - how do changes to the domain ontology affect the mappings and when are changes reflected?

Two open source healthcare information systems reviewed are - PatientOS

(PatientOS, 2009) and Red Hat Enterprise Platform (Red Hat Inc., 2007). PatientOS provides development and implementation services for hospitals and clinics which is said to enhance the clinician's work-flow by providing relevant clinical information. Red Hat

Inc. (2007) offers a package including Red Hat® Enterprise Linux®, JBoss Enterprise

Middleware, updates via Red Hat Network and customer support services in a cost- effective IT platform. It uses Red Hat Enterprise MRG to implement an open Advanced

Message Queuing Protocol standard to provide affordable, scalable message transport over Traditional message transports for HL7 which is deemed either too expensive or does not scale very well. Our FODA4SWS methodology uses Internet technology to deploy services which means services are potentially globally accessible. This suggests that FODA4SWS could potentially scale better than tools with a less extendible framework.

147

CHAPTER 5

CONCLUSION

The lack of interoperability in healthcare hinders efficiency, the delivery of quality care at a reduced cost and access to safe patient care. Injuries resulting from ADEs can be prevented or reduced with integrated and interoperable business processes. The focus of this essay was therefore to develop a design methodology for e-health that would offer enhanced interoperability between e-health systems, towards improving communication and collaboration between systems in the e-health domain.

The e-heath domain is a complex domain with many different categories of information systems and supporting bodies of knowledge or domain ontologies. To achieve interoperability, services need to be able to communicate and collaborate regardless of inhibiting factors such as location, heterogeneous languages or ontologies.

Our proposed methodology - Feature-Oriented Domain Analysis for Semantic

Web services (FODA4SWS) combines MDD with Ontologies in an integrated SOPL implementation with the following contributions:

• The SOPL framework is structured for longevity with a service-base architecture

that offers reusability, agility, flexibility and adaptability which is considered to

be well suited for the e-health domain. The use of Web services technology adds

extensibility to the life of the software in that services can be used to wrap and

expose functionalities of legacy systems (present and future)

148

• SOPL framework offers benefits such as shorter time to market and reduced

development cost to the healthcare domain

• Interoperability and integration are offered on different levels which enhances the

outcome for a highly interoperability e-health domain

1) The use of ontologies at the different layers of MDA allows for ontology

mapping which facilitates improved interoperability, automation and

traceability between models

2) SAWSDL facilitates semantic interoperability through ontology mappings

3) Semantic Web Services allows for seamless integration of different

healthcare standards with ontologies, facilitating interoperability

4) Services promote integration with the ability to connect applications across

geographical boundaries and ontology mismatch

5) Interoperability was thought to be most effective at the business process

level allowing for business process integration and collaboration of

services

• Interoperability in healthcare means that healthcare providers would have access

to information when needed, and be able to make evidence-based decision. This

translates to reduction or elimination of preventable ADEs and safer patient care

• Improvement in healthcare interoperability comes with added benefits such as

improved quality of care, better patient experience, reduction in healthcare costs

and improved efficiency in the delivery of healthcare

149

We illustrated our methodology with an e-prescription case study and propose that it can be used to effectively improve interoperability and address issues of ADEs. By extension, we propose that FODA4SWS can potentially be applied to other domains to address issues of interoperability, integration and communication between distributed systems.

RECOMMENDATIONS FOR FUTURE WORK

We did not fully evaluate the existence and effectiveness of current tool support.

However, from the tools reviewed, the FeatureMapper tool (which maps features from feature models to their realization in the solution space) was seen as a very likely tool that could be extended with ontology processing such that a semantically annotated feature model can map to an annotated business process (or other solution space) model. In light of this, future work would likely take the direction of performing more thorough investigations of current feature modeling or feature mapping tools (such as

FeatureMapper), and to look at extending the tool to incorporate ontologies in the mappings or transformations from source to target models.

Another potential area for future work is to merge the feature mapping capabilities of FeatureMapper with WSMO Studio/BPMO Modeler for a complete tool that supports the process from feature modeling through to Semantic Web service modeling and derivation.

150

REFERENCES

AHRQ - Agency for Healthcare Research and Quality - U.S. Department of Health &

Human Services (2001). Reducing and Preventing Adverse Drug Events To

Decrease Hospital Costs. Retrieved from

http://www.ahrq.gov/qual/aderia/aderia.htm

Akkiraju, R., Farrell, J., Miller, J., Nagarajan, M., Schmidt, T., Sheth, A. & Verma, K.

(2005). Web Service Semantics - WSDL-S. Retrieved from

http://www.w3.org/Submission/WSDL-S/

Akkiraju, R. & Sapkota, B. (2007). Semantic Annotations for WSDL and XML Schema

— Usage Guide. W3C Working Group. Retrieved from

http://www.w3.org/TR/sawsdl-guide/

Alana, E., Rodriguez A., GMV Domain Engineering Methodology Survey (2007).

CORDET. Retrieved from http://www.pnp-

software.com/cordet/download/pdf/GMV-CORDET-RP-001_Iss1.pdf

Anquetil, N., Grammel, B., Galvão, I., Noppen, J., Khan, S. S., Arboleda, H., Rashid, A.

& Garcia, A. (2008) . Traceability for Model Driven, Software Product Line

Engineering. In ECMDA Traceability Workshop Proceedings. Berlin, Germany.

Antkiewicz, M., & Czarnecki. K. (2004). FeaturePlugin: Feature Modeling Plug-In for

Eclipse. In Eclipse Technology eXchange (ETX) Workshop. Presented at the

Object Oriented Programming, Systems, Languages and Applications 2004,

ACM. Retrieved from http://www.swen.uwaterloo.ca/~kczarnec/etx04.pdf

151

Arroyo, S., Bussler, C., Kopecky, J., Lara, R., Polleres, A., Zaremba, M. (2004). Web

Service Capabilities and Constraints in WSMO. Retrieved from

http://www.w3.org/2004/08/ws-cc/wsmo-20040903

Asadi, M., Mohabbati, B., Kaviani, N., Gaševi, D., Boškovi, M., & Hatala, M. (2009).

Model-Driven Development of Families of Service-Oriented Architectures. In

Proceedings of the First International Workshop on Feature-Oriented Software

Development (FOSD’09). Denver, CO, USA. ACM

ATL - Atlas Transformation Language (n.d.). Eclipse. Retrieved from

http://www.eclipse.org/atl/

Austin, C. J. & Boxerman, S. B. (2003). Information Systems for Healthcare

Management, 6th Edition. Health Administration Press © 2003 Citation

Austin, D., Barbir, A., Ferris, C. & Garg, S. (2004). Web Services Architecture

Requirements. Retrieved from http://www.w3.org/TR/wsa-reqs/

Bae, J. & Kang, S. (2007). A Method to Generate a Feature Model from a Business

Process Model for Business Applications. In 7th International Conference on

Computer and Information Technology (pp. 879 - 884). IEEE.

Bates, D., Boyle D., Vander Vliet V., et al. (1995a). Relationship between medication

errors and adverse drug events. J Gen Intern Med 1995;10:199–205.

Bates, D., Cullen, D., Laird, N. et al. (1995b). Incidence of adverse drug events and

potential adverse drug events - Implications for prevention. JAMA. Volume 274,

Page 29–34.

Batory, D. (1998) Product-Line Architectures. In Smalltalk and Java in Industry and

Practical Training. Erfurt, Germany. 152

Battle, S., Bernstein, A., Boley, H., Grosof, B., Gruninger, M. & Hull, R. et al. (2005).

Semantic Web Services Framework (SWSF) Overview. Retrieved from

http://www.w3.org/Submission/SWSF/

Bayer, J. & Widen, T. (2001). Introducing traceability to product lines. In Fourth

International Workshop on Product Family Engineering (PFE-4), Page 399-40.

Bean, J. (2009). SOA and Web Services Interface Design: Principles, Techniques, and

Standards. Morgan Kaufman.

Bell, Michael (2009). SOA Modeling Patterns for Service Oriented Discovery and

Analysis. John Wiley & Sons, Inc.

Benavides, D., Segura, S., Trinidad, P., & Ruíz-Cortés, P. (2007). FAMA: Tooling a

Framework for the Automated Analysis of Feature Models. In the First

International Workshop on Variability Modelling of Software-intensive Systems

(VaMoS’07). Limerick. Ireland.

Berners-Lee, T., Hendler, J. & Lassila, O. (2001). The Semantic Web: A new form of

Web content that is meaningful to computers will unleash a revolution of new

possibilities. Scientific American. Online Article. Retrieved from

http://www.scientificamerican.com/article.cfm?id=the-semantic-web

Berre, A., Benguria, G., Cerri, D., et al. (2008). Semantically-enabled Heterogeneous

Service Architecture and Platforms Engineering - SHAPE Project ICT-2007-

216408. Retrieved from http://www.shape-project.eu/

Bontemps, Y. & Heymans, P. (2004). Semantics of FODA Feature Diagrams. In SPLC

2004.

153

Booth, D., Haas, H. & McCabe, F. (2004). Web Services Architecture. Retrieved from

http://www.w3.org/TR/ws-arch/

Brailer, D. J. (2005). Interoperability: The key to the future health care system. Health

Affairs.

Brambilla, M., Ceri, S., Facca, F., Celino, I., Cerizza, D. & Valle, E. D. (2007). Model-

driven design and development of semantic Web service applications. ACM.

Brown, A. (2004). An Introduction to Model Driven Architecture. IBM. Retrieved from

http://www.ibm.com/developerworks/rational/library/3100.html#N1011E

Cabral, L., Domingue, J., Motta, E., Payne, T. & Hakimpour, F. (2004). Approaches to

Semantic Web Services: an Overview and Comparisons. In The Semantic Web:

Research and Applications, Lecture Notes in Computer Science. (Vol. 3053, pp.

225 - 239). Springer. Berlin, Germany.

Cardoso, J. & Sheth, A., Eds. (2006). Semantic Web Services, Processes and

Applications. Springer.

Cardoso, J. (2007). Semantic Web Services: Theory, Tools and Applications. Information

Science Reference. USA.

Casanave, C. (2009). Enterprise Service Oriented Architecture Using the OMG SoaML

Standard.

Centers for Medicare & Medicaid Service - CMS (n.d.). Overview E-prescribing.

Retrieved from https://www.cms.gov/eprescribing/

Chinnici, R., Moreau, J., Ryman, A. & Weerawarana, S. (2007). Web Services

Description Language (WSDL) Version 2.0 Part 1: Core Language. Retrieved

from http://www.w3.org/TR/2007/REC-wsdl20-20070626 154

Clement, L., Hately, A. von Riegen, C., Rogers, T. (2004). Universal Description

Discovery & Integration (UDDI) Specification TC. Version 3.0.2. Retrieved from

http://uddi.org/pubs/uddi_v3.htm

Cohen, S. (2010). SOA and Systematic Reuse for Health Information Exchange Systems.

Software Engineering Institute, Carnegie Mellon University. USA.

Cohen, S. & Krut, R. (2010). Managing Variation in Services in a Software Product Line

Context. SEI/CMU. Retrieved from http://www.sei.cmu.edu/reports/10tn007.pdf

Cummins, F. A. (2008). Enabling the Agile Enterprise with SOA, BPM and MPM.

Morgan Kaufmann.

Czarnecki, K. (2004). Overview of Generative Software Development. Unconventional

Programming Paradigms International Workshop UPP 2004, Lecture Notes in

Computer Science (LNCS), 2005, Volume 3566, Page 326 – 341.

Czarnecki, K., Antkiewicz, M., Kim, C. H. P., Lau, S. & Pietroszek, K. (2005). Model-

driven Software Product Lines. In Conference on Object-oriented Programming,

Systems, Languages, and Applications (OOPSLA ’05). ACM SIGPLAN.

Czarnecki, K., Kim, C. H. P., & Kalleberg, K. T. (2006). Feature Models are Views on

Ontologies. In The 10th International Software Product Line Conference (SPLC

2006). IEEE.

Dean, M. & Schreiber, G. (2004). OWL Web Ontology Language Reference. Retrieved

from http://www.w3.org/TR/owl-ref/

Della Valle, E., Cerizza, D. (2005). Cocoon Glue: a prototype of WSMO discovery

engine for the healthcare field. In Proceedings of 2nd WSMO Implementation

Workshop. 155

Dijkman, R. M., Dumas, M. & Ouyang, C. (2008). Semantics and analysis of business

process models in BPMN. (pp. 1281- 1294).

Dogac, A., Laleci, G., Kirbas, S., Kabak, Y., Sinir S. & Yildiz, A.(2003). Artemis:

Deploying Semantically Enriched Web Services in the Healthcare Domain

Dogdu, E. (2009). Semantic Web in eHealth. In the 47th ACM Southeast Conference,

Clemson University: ACM New York, NY, USA.

Domingue, J., Brelage, C., Leymann, F. et al. (2008a). SUPER (Semantics Utilised for

Process management within and between EnteRprises) Integrated Project.

Retrieved from http://www.ip-super.org

Domingue, J., Jedrzejczak, A., Filipowska, A., Starzecka, M., Stolarski, P., Walczak, A.,

Wecel, K. (2008b).Project IST 026850 SUPER. Deliverable 4.5. Retrieved from

http://www.ip-super.org/res/Deliverables/M24/D4.5.pdf

Elvesæter, B., Carrez, C., Mohagheghi, P., Berre, A., Johnsen, S. G. & Solberg, A.

Model-Based Development with SoaML. Retrieved from

http://www.uio.no/studier/emner/matnat/ifi/INF5120/v10/undervisningsmateriale/

MDSE-SoaML-INF5120.pdf

Elvesæter, B, Panfilenko, D., Jacobi, S., Hahn, C. (2010). Aligning business and IT

models in service-oriented architectures using BPMN and SoaML. In MDI '10

Proceedings of the First International Workshop on Model-Driven

Interoperability. ACM. New York.

Erl, Thomas (2005). Service-Oriented Architecture: Concepts, Technology, and Design.

Prentice Hall. PTR, NJ, USA.

156

Farrell, J & Lausen, H. (2007). Semantic Annotations for WSDL and XML Schema

(SAWSDL). Retrieved from http://www.w3.org/TR/sawsdl/

Gaševi, D., Djuri & Devedži (2009b). Model Driven Engineering and Ontology

Development. Springer.

Gaševi, D., Djuri, D. & Devedži, V., Selic, B. (2006). Model Driven Architecture and

Ontology Development. Springer.

Gaševi, D., Kaviani, N., & Milanovic, M. (2009a). Ontologies and Software

Engineering. Handbook on Ontologies, (pp.593-615). Springer.

Gaševi, D., & Hatala, M. (2010). Model-Driven Engineering of Service-Oriented

Systems. In The International Journal of Service Science, Management,

Engineering, and Technology (IJSSMET). (Vol. 1, pp. 17-32).

Gehlot, V., & Sloane, E. B. (2006). Ensuring Patient Safety in Wireless Medical Device

Networks. IEEE Computer Society.

Giner, P., Torres, V., & Pelechano, V. Bridging the Gap between BPMN and WS-BPEL.

M2M Transformations in Practice.

Gómez, J. M. & Mahmoud, T (2008). Integration of Semantic Web Services Principles in

SOA to Solve EAI and ERP Scenarios Towards Semantic Service Oriented

Architecture.

Griss, M. L., Favaro, J. & d'Alessandro, M. (1998). Integrating Feature Modeling with

the RSEB. In Proceedings of the 5th International Conference on Software Reuse

(pp. 76 - 85). IEEE Computer Society.

Gröner, G., Wende, C., Boškovi, M., Silva Parreiras, F., Walter, T., Heidenreich, F.,

Gaševi, D. & Staab, S. (2011). "Validation of Families of Business Processes," 157

In Proceedings of the 23rd International Conference on Advanced Information

Systems Engineering, London, UK, 2011 (in press).

Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., Nielsen, H. F. Et al. (2007). SOAP

Version 1.2 Part 1: Messaging Framework (Second Edition). Retrieved from

http://www.w3.org/TR/soap12-part1/

Hahn, C., Shafiq, O., Benguria, G., Kämper, S. & Berre, J. (2009). Semantically-enabled

Heterogeneous Service Architecture and Platforms Engineering - SHAPE Project

No 216408. Model transformation and deployment architecture description.

Deliverable D5.1. Retrieved from http://www.shape-project.eu/wp-

content/uploads/2009/01/shape_d51.pdf

Hale, P. L. (2007). Electronic Prescribing: A Brief History. In Electronic Prescribing for

the Medical Practice. Chapter 1. Retrieved from

http://www.himss.org/content/files/EPrescribing_Hale_Chapter_1.pdf

Hatala, M., Mohabbati B., Asadi M., Boškovi M., and Gaševi D. (2011). Development

and configuration of service-oriented software product lines. In Proceedings of

the 26th ACM Symposium on Applied Computing (SAC’11). ACM.

Health Canada. (2007). Policy Statement on E-prescribing. Retrieved from

http://www.hc-sc.gc.ca/hcs-sss/ehealth-esante/e_presc-ord_elec-eng.php

Healthcare Services Specification Project, Health Level Seven, Object Management

Group. The Practical Guide for SOA in Health Care: A real-world approach to

planning, designing, and deploying SOA. Retrieved from

http://hssp.wikispaces.com/file/view/2008-12-

29+SOA%2BHealthcare%2BPractical%2BGuide%2Bv1.0.pdf 158

Health Level 7 Reference Information Model. Retrieved from http://www.hl7.org/

Heidenreich, F., Kopcsek, J. & Wende, C. (2008). FeatureMapper: Mapping Features to

Models. In Companion Proceedings of the 30th International Conference on

Software Engineering (ICSE'08). Leipzig, Germany.

Hepp, M., Leymann, F., Domingue, J., Wahler, A. & Fensel, D. (2005). Semantic

Business Process Management: A Vision Towards Using Semantic

Web Services for Business Process Management. Presented at the ICEBE, IEEE.

Herman, I., Hawke, S., Prud’hommeaux, E. & Swick, R. (2011). W3C Semantic Web

Activity. Retrieved from http://www.w3.org/2001/sw/

HIMSS. (2010). EHR – Electronic Health Record. (Healthcare Information and

Management Systems Society). Retrieved from

http://www.himss.org/ASP/topics_ehr.asp

HIMSS. (n.d.). Integration & Interoperability. (Healthcare Information and Management

Systems Society). Retrieved from

http://www.himss.org/ASP/topics_integration.asp

IHTSDO: International Health Terminology Standards Development Organisation.

Retrieved from http://www.ihtsdo.org/

Infoway. (2008). SNOMED CT. Canada Health Infoway. Retrieved from

https://sl.infoway-inforoute.ca/content/disppage.asp?cw_page=snomedct_e

Infoway. (2011a). Canada Health Infoway. Retrieved from http://www.infoway-

inforoute.ca/lang-en/

Infoway (2011b). Benefits of Electronic Health Records (EHRs). Canada Health

Infoway. Retrieved from https://www.infoway-inforoute.ca/about-ehr/benefits 159

Infoway. (n.d.). CeRx Messaging Standard. Canada Health Infoway.

InterOP (n.d.). State of the Art Report 3. Ontology Interoperability Information Society.

Johansen, M. F., Fleurey, F., Acher, M., Collet, P. & Lahire, P. (2010). Exploring the

Synergies Between Feature Models and Ontologies. Retrieved from

http://folk.uio.no/martifag/papers/Johansen2010.pdf

Jordan, D. & Evdemon, J. (2007). Business Process Execution Language (BPEL) for

Web-Services 2.0. Retrieved from http://www.oasis-

open.org/committees/download.php/10347/wsbpel-specification-draft-

120204.htm, 2007

Jouault, F., Allilaire, F., Bézivin, J. &Kurtev, I.. (2008). ATL: A model transformation

tool. Science of Computer Programming 72(1-2), 31–39 (2008)

Juric, M. & Pant, K. (2008). Business Process Driven SOA using BPMN and BPEL:

From Business Process Modeling to Orchestration and Service Oriented

Architecture. Scroff.

Kang, D. & Baik, D. (2010). Bridging Software Product Lines and Service-Oriented

Architectures for Service Identification using BPM and FM. IEEE.

Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E., & Peterson, A. S. (1990). Feature-

Oriented Domain Analysis (FODA) Feasibility Study (No. CMU/SEI-90-TR-21

ESD-90-TR-222). Software Engineering Institute, Carnegie Mellon University.

Retrieved from http://www.sei.cmu.edu/reports/90tr021.pdf

Kashyap, V., Bussler, C., Moran, M. (2008). The Semantic Web: Semantics for Data and

Services on the Web. Springer.

160

Kaviani, N., Gaševi, D., Karimifar, M., Hatala, M., Sheidaei, S. (2007) Rule Modeling

to Unify Policies and Processes in Service-Oriented Health Information Systems.

Retrieved from http://mothis.isis.vanderbilt.edu/papers/rule.pdf

Kaviani, N., Mohabbati, B., Gaševi, D., Finke, M. (2008). Semantic Annotations of

Feature Models for Dynamic Product Configuration in Ubiquitous Environments

(SWESE 2008). Retrieved from

http://www.abdn.ac.uk/~r01srt7/swese2008/pdf/swese2008_submission_18.pdf

Kemsley, Sandy. (2008). Using BPM to Prioritize Service Creation. In TUCON 08.

Retrieved from http://www.slideshare.net/skemsley/using-bpm-to-prioritize-

service-creation

Kohn, L. T., Corrigan, J. M., Donaldson, M. S. (1999). To Err Is Human: Building a

Safer Health System. Washington, DC: National Academy Press. Retrieved from

http://www.providersedge.com/ehdocs/ehr_articles/To_Err_Is_Human_%20Build

ing_a_Safer_Health_System-exec_summary.pdf

Kou, S., Babar, M. A., Sangrota. A. (2010). Modeling Security for Service Oriented

Applications. In the Fourth European Conference on Software Architecture

(ECSA ’10). ACM.

Lausen, H., Polleres, A. & Roman, D. (2005). Web Service Modeling Ontology

(WSMO). W3C Member Submission. Retrieved from

http://www.w3.org/Submission/WSMO/

Lawrence, K. & Kaler, C. (February, 2006). Web Services Security: SOAP Message

Security 1.1. Retrieved from http://www.oasis-

161

open.org/committees/download.php/16790/wss-v1.1-spec-os-

SOAPMessageSecurity.pdf

Lewis, G. A. & Wrage, L. (2005). Model Problems in Technologies for Interoperability:

Model-Driven Architecture. In Integration of Software-Intensive Systems (ISIS)

Initiative. Retrieved from http://www.sei.cmu.edu/reports/05tn022.pdf.

Leymann, F., & Roller, D. (2002). Business processes in a Web services world: A quick

overview of BPEL4WS. IBM. Retrieved from

http://www.ibm.com/developerworks/webservices/library/ws-bpelwp/.

Long, A., Horvath, M., Cozart, H., Eckstrand, J.,Whitehurst, J. & Ferranti, J. (2010).

Tailoring adverse drug event surveillance to the paediatric inpatient.

LSDIS - Large Scale Distributed Information Systems. (2005). SAWSDL: Semantic

Annotations for WSDL. Retrieved from http://lsdis.cs.uga.edu/projects/meteor-

s/SAWSDL/

Martin, D. et al. (2004). OWL-S: Semantic Markup for Web Services. Retrieved from

http://www.w3.org/Submission/OWL-S/

Martin, D. et al. (2008). OWL-S 1.2 Release. Retrieved from

http://www.ai.sri.com/daml/services/owl-s/1.2/

Medicare Australia. (2010). Electronic prescribing and dispensing of medicines.

Retrieved from

http://www.medicareaustralia.gov.au/provider/pbs/pharmacists/dispense.jsp

Milanovi, M. & Gaševi, D. (2009). Towards a Language for Rule-enhanced Business

Process Modeling. Presented at the IEEE International Enterprise Distributed

Object Computing Conference. 162

Milanovic, M., Gaševi, D., Wagner and Devedži. (2009). Modeling Service

Orchestrations with a Rule-enhanced Business Process Language.

Miller, E. Semantic Web in Health-care and Life Sciences - Applications and

Demonstrations. Retrieved from http://www.w3.org/2005/04/swls/

Miller, J., & Mukerji, J. (2003). MDA Guide. OMG. Retrieved from

http://www.enterprise-architecture.info/Images/MDA/MDA%20Guide%20v1-0-

1.pdf

MITRE Corporation. (2006). Electronic Health Records Overview. (National Institutes of

Health, National Center for Research Resources - NIH, NCRR). Retrieved from

http://www.ncrr.nih.gov/publications/informatics/ehr.pdf#7

Modeliosoft. (2009). Modelio, UML modeling tool – MDA, Business process and

software architecture design. Retrieved from http://www.modeliosoft.com/

Mohabbati, B., Kaviani, N. & Gaševi, D. (2009). Semantic Variability Modeling for

Multi-staged Service Composition. (SOAPL2009). Retrieved from

http://www.sei.cmu.edu/splc2009/files/Mohabbati_SOAPL2009.pdf

Montero, I., Peña, J. & Ruiz-Cortés, A. (2008). ATL Transformation: Feature Models for

representing runtime variability in BIS to Business Process Model Notation.

Retrieved from http://www.isa.us.es/uploads/tools/fm2bpmn/doc/draft.pdf

Nebeker J. R., Barach P., Samore M.H. (2004). Clarifying adverse drug events: a

clinician’s guide to terminology, documentation, and reporting. Ann Intern Med.

Volume 140, Page 795-801.

163

Nelson, S. J., Zeng, K., Kilbourne, J. Building a Standards-Based and Collaborative E-

Prescribing Tool – MyRxPad. U.S. National Library of Medicine. Retrieved from

http://www.nlm.nih.gov/mesh/myrxpad_amia2009.html

Nickul, D., Reitman, L., Ward, J., Wilber, J. (2007). Service Oriented Architecture

(SOA) and Specialized Messaging Patterns. Technical White paper. Adobe

Systems Inc. USA.

Nietzsche, F. “The strongest have their moments of fatigue”

NIST - National Institute of Standards and Technology. (2008). Process Specification

Language (PSL). Retrieved from http://www.mel.nist.gov/psl/

Northrop, L. (2002). Initiating Software Product Lines: SEI’s Software Product Line

Tenets. Software Engineering Institute. IEEE Software.

Northrop, L. (2008). Software Product Line Essentials. Software Engineering Institute,

Carnegie Mellon University. Pittsburg, PA, USA.

Obrst, Lee. (2003). Ontologies for Semantically Interoperable Systems. ACM

In 2003 Proceedings of the 12th International Conference on Information and

Knowledge Management (CIKM’03). (pp. 366-369). New Orleans, LA, USA:

ACM.

OMG. (2009a). Business Process Management Notation (BPMN) Version 1.2.,

formal/2009-01-03, The Object Management Group. Retrieved from

http://www.omg.org/spec/BPMN/1.2

OMG. (2009b). Ontology Definition Metamodel (ODM). Retrieved from

http://www.omg.org/spec/ODM/1.0/

164

OMG, (2009c). Service oriented architecture Modeling Language (SoaML) –

Specification for the UML Profile and Metamodel for Services (UPMS).

Retrieved from http://www.omg.org/spec/SoaML/1.0/Beta2/PDF/

OMG. (2010). MDA Specifications. Retrieved from http://www.omg.org/mda/specs.htm

Ort, Ed (2005). Service-Oriented Architecture and Web Services: Concepts,

Technologies, and Tools. Sun Developer Network. Retrieved from

http://java.sun.com/developer/technicalArticles/WebServices/soa2/SOATerms.htm

l#soawhy

Ouyang, C., Dumas, M., van der Aalst, W. M. P. & ter Hofstede, A. H. M. (2006b).

SADI. From Business Process Models to Process-oriented Software Systems: The

BPMN to BPEL Way Retrieved from

http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/reports/2006/BPM-06-27.pdf

Ouyang, C., van der Aalst, W. M.P., Dumas, M., & ter Hofstede, A. H. M. (2006a).

Translating BPMN to BPEL. Retrieved from

http://wwwis.win.tue.nl/~wvdaalst/BPMcenter/reports/2006/BPM-06-02.pdf

Pahl, C. (2007). Semantic model-driven architecting of service-based software systems,

(pp. 838-850).

Papazoglou, M., Traverso, P., Dustdar, S & Leymann, F. (2007). Service-Oriented

Computing: State of the Art and Research Challenges. Computer, Page 64–71.

IEEE.

Parastatidis, S. Watson, P. & Webber, J. (2005). Grid Computing Using Web Services

Technologies.

165

PatientOS. (2007). PatientOS - an Open Source (GPL) Healthcare Information System.

Retrieved from http://www.patientos.org/

Pedrinaci, C., Domingue, J. & Brelage, C. (2008). Semantic Business Process

Management: Scaling up the Management of Business Processes. In IEEE

International Conference on Semantic Computing.

Perovich, D., Rossel, P. O. & Bastarrica, M. C. (2009). Feature Model to Product

Architectures: Applying MDE to Software Product Lines. IEEE.

Pohl, K., Böckle, G. & van der Linden, F. (2005). Software Product Line Engineering:

Foundations, Principles, and Techniques. Berlin, Germany: Springer.

Prud'hommeaux, E. & Seaborne, A. (2008). SPARQL Query Language for RDF.

Retrieved from http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/

Puustjärvi, J. & Puustjärvi, L. (2006). Improving the Quality of Medication by Semantic

Web Technologies. Retrieved from

http://www.stes.fi/scai2006/proceedings/step2006-46-puustjarvi-improving-the-

quality-of-medication.pdf

Raghupathi, W. & Kesh, S. (2007). Interoperable Electronic Health Records

Design:Towards a Service-Oriented Architecture.

Raghupathi, W. & Umar, A. (2008). Exploring a model-driven architecture (MDA)

approach to health care information systems development. In International

journal of medical informatics. Volume 77, Issue 5 (pp. 305–314).

RDF Working Group, W3C. (2004). Resource Description Framework (RDF). Retrieved

from http://www.w3.org/RDF/

166

Red Hat Inc. (2007). Red Hat Enterprise Healthcare Platform. Retrieved from

http://www.redhat.com/f/pdf/healthcarebattlecard_web.pdf

Regio, M., & Greenfield, J. (2005). Designing and Implementing an HL7 Software

Factory. Software Factories. Retrieved from

http://softwarefactories.com/workshops/OOPSLA-2005/Papers/Regio.pdf

Regio, M., Greenfield, J. & Thuman, B. (2005). A Software Factory Approach To HL7

Version 3 Solutions. Retrieved from http://msdn.microsoft.com/en-

us/library/ms954602.aspx Microsoft Development Network (MSDN). Microsoft

Corporation.

Rohlik, O. & Pasetti, A. (2004). XFeature: Feature Modelling Tool. Retrieved from

http://www.pnp-software.com/XFeature/

Roman, D., Lausen, H. & Keller, U. (2006). Web Service Modeling Ontology (WSMO).

(2006). Version D2v1.3. Retrieved from http://www.wsmo.org/TR/d2/v1.3/

Roshen, W. (2009). SOA-based enterprise integration: a step-by-step guide to services-

based. McGraw Hill Professional, 2009.

Rusk, J. (2009). Semantic Web Services-Based Reasoning in the Design of Software

Product Lines. Athabasca University, Canada. Retrieved from

http://library.athabascau.ca/drr/download.php?filename=scis-

07/open/JeffRuskIntegratedProject.pdf

Rusk, J. & Gaševi, D. (2008). Semantic Web Services-based Reasoning in the Design of

Software Product Lines. Athabasca University Canada. Retrieved from

http://www.sei.cmu.edu/library/assets/Rusk.pdf

167

Ryan, A. (2006). Towards semantic Interoperability in healthcare: ontology mapping

from SNOMED-CT to HL7 version 3. In Proceedings of 2006 Australasian

Ontology Workshop (AOW2006). Tasmania, Australia.

Sanders, D. T., Hamilton Jr., J. A. & MacDonald, R. A. (2008). Supporting A Service-

Oriented Architecture. In Proceedings of the 2008 Spring simulation

multiconference (SpringSim ’08). Ottawa, Canada.

Schroth, C. & Janner, T. (2007). Web 2.0 and SOA: Converging Concepts Enabling the

Internet of Services. IEEE.

SEI/CMU. (2009). A Framework for Software Product Line Practice, Version 5.0.

(Software Engineering Institute/ SEI Carnegie Mellon University). Retrieved from

http://www.sei.cmu.edu/productlines/frame_report/index.html

SEI/CMU. (n.d.-1). Software Product Lines - Case Studies. (Software Engineering

Institute / Carnegie Mellon University). Retrieved from

http://www.sei.cmu.edu/productlines/casestudies/

SEI/CMU.(n.d.-2). Software Product Lines. ( Software Engineering Institute / Carnegie

Mellon University). Retrieved from http://www.sei.cmu.edu/productlines/

Smith, B. (2009). Service-Oriented Architecture (SOA) and Software Product Lines: Pre-

Implementation Decisions. In Workshop on Service-Oriented Architectures and

Software Product Lines. 13th International Software Product Line Conference.

Retrieved from http://www.sei.cmu.edu/splc2009/files/Smith_SOAPL2009.pdf

Standish (1994). The CHAOS Report. The Standish Group International. Retrieved from

http://www.standishgroup.com/sample_research/chaos_1994_1.php

168

Stephens, M., Fox B., Kukulka G., Bellamy J. (2008). Medication, allergy and adverse

drug event discrepancies in ambulatory care. Family Medicine. Volume 40,

Number 2. Page:107–110.

Stroetmann K. A. & Strtoetmann V. N. (2005). Towards an Interoperability Framework

for a European e-Health Research Area–Locating the Semantic Interoperability

Domain. WHO/EC Workshop on Semantic interoperability. Brussels.

Studer, R., Grimm, S., & Abecker, A. (2007). Semantic Web Service: Concepts,

Technologies, and Applications. Springer. Berlin, Germany.

Taylor, P. (2006). From Patient Data to Medical Knowledge: The Principles and Practice

of Health Informatics. BMJ Books: Blackwell Publishing.

Verma, K., Sheth, A. (2007). Using SAWSDL for Semantic Service Interoperability.

Tutorial at Semantic Technology Conference, San Jose, CA, May 21, 2007.

Wahli, U., Burroughs, O., Cline, O., Go, A. & Tung, L. (2006). Web Services Handbook

for WebSphere Application Server 6.1. IBM. Retrieved from

http://www.redbooks.ibm.com/redbooks/pdfs/sg247257.pdf

Wang, H., Li, Y. F., Sun, J., Zhang, H., & Pan, J. (2005). A Semantic Web Approach to

Feature Modeling and Verification. In 1st Workshop on Semantic Web Enabled

Software Engineering (SWESE’05). Galway, Ireland.

Wetzstein, B., Ma, Z., Filipowska, A. (2007). Semantic Business Process Management:

A Lifecycle Based Requirements Analysis. In Proceedings of theWorkshop on

Semantic Business Process and Product Lifecycle Management (SBPM 2007) in

conjunction with the 3rd European Semantic Web Conference (ESWC 2007).

169

Retrieved from http://www.sti-

innsbruck.at/results/browse/proceedings/details/?uid=31

White, S. A. (2004). Introduction to BPMN. Retrieved from

http://www.bptrends.com/publicationfiles/07-

04%20WP%20Intro%20to%20BPMN%20-%20White.pdf

WHO. (2008). Medicines: safety of medicines – adverse drug reactions. (World Health

Organization). Retrieved from

http://www.who.int/mediacentre/factsheets/fs293/en/

WHO. (2010). Medicines: rational use of medicines. (World Health Organization).

Retrieved from http://www.who.int/mediacentre/factsheets/fs338/en/

Wickramasinghe, N., Gupta, J. & Sharma, S. (2005). Creating Knowledge-Based

Healthcare Organization. IGI Global.

Wolf, C. & Harmon, P. (2006). The State of Business Process Management. BPTrends.

Retrieved from http://www.ip-super.org/res/related/State_of_BPM_2006.pdf

W3C. (2005). Health Care and Life Sciences (HCLS) Interest Group. Retrieved from

http://www.w3.org/2001/sw/hcls/

W3C. (2007). Semantic Annotations for WSDL and XML Schema - SAWSDL).

Retrieved from http://www.w3.org/TR/sawsdl/

W3C. (2010a). Semantic Web. Retrieved from

http://www.w3.org/standards/semanticweb/

W3C. (2010b). Vocabularies. Retrieved from

http://www.w3.org/standards/semanticweb/ontology

W3C. (2010c). Query. Retrieved from http://www.w3.org/standards/semanticweb/query 170

W3C. (2010d). Inference. Retrieved from

http://www.w3.org/standards/semanticweb/inference

W3C. (2010e). Vertical Applications. Retrieved from

http://www.w3.org/standards/semanticweb/applications

WSMX. (2008). Web Services Execution Environment. Retrieved from

http://www.wsmx.org/.

Yan, Z., Cimpian, E., Mazzara, M., & Zaremba, M. (2007). BPMO: Semantic Business

Process Modeling and WSMO Extension. IEEE.

Zaid, L. A., Kleinermann, F., De Troyer, O. (2009). Applying Semantic Web Technology

to Feature Modeling. In Symposium on Applied Computing (SAC ’09). ACM.

171