A Systematic Approach to Service-Oriented Analysis and Design

Abstract

Abstract. Service-oriented computing (SOC) has several unique features which are not typically presented in conventional object-oriented development (OOD) and component-based development (CBD), including the commonalty of service functionality, publish and discovery paradigm of services and dynamic composition of possibly 3 rd party's independent unit services. Hence, OOD and CBD-based analysis and design methods are not effective and expressive enough to model service-oriented applications. Rather, Service-Oriented Analysis and Design (SOAD) has to be defined by using some of the two modeling paradigms and by adding SOC-unique modeling mechanisms. In this paper, we first present a technical comparison among OOD, CBD and SOAD to derive the design criteria for SOAD. And, we define the key artifacts that have to be delivered during SOAD. Based on this, we present a SOAD process which takes service requirements as the initial input and delivers service specifications, compositions, and verified service components as the final deliverables. Each of the five phases in the process is defined with its overview, artifacts, and work instructions. Finally, we present a case study of applying our process to a service domain to reveal its effectiveness and applicability. Once the proposed SOAD is well applied, SOAD artifacts can be more systematically and efficiently implemented with current SOA standards.

Enhancing the OPEN Process Framework with service-oriented method fragments

“…These latter phases form a lighter process during maintenance.  SDM proposed by Chang and Kim [ 62]: The SDM contains five phases namely identifying business processes, defining unit services, discovering services, developing services and composing services.  Steve Jones' Service Architectures [ 63]: This SDM is based on the idea of decomposing business processes of organizations into business services resulting in business service architectures of organizations.…”

Automatic service derivation from business process model repositories via semantic technology

“…For instance, Adamopoulos et al [3] as well as Chang and Kim [4] propose methods to employ a general analysis of service requirements as starting point for service derivation. Similarly, Arsanjani and Allam [38] propose a three-step approach for deriving service candidates from different business capabilities.…”

“…Among others, these approaches leverage requirements documents [3,4], different types of conceptual models [5,6,7], and source code [8,9,10]. Due to their general availability, particularly process models have turned out as a valuable source for identifying services.…”

“…In the beginning, a list for the composite candidates is created (line 2). In the subsequent loop, each activity label from the set L C of all activity labels is inspected (lines [3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19]. If the candidate list already contains a candidate with a semantically identical business object, it is checked whether the business object from the current label is syntactically different (lines [6][7][8][9].…”

“…It starts by defining a list for the hierarchical candidates (line 2). Subsequently, each activity label is analyzed in the context of a loop (lines [3][4][5][6][7][8][9][10][11][12]. In this loop, it is first checked whether the candidate list already contains a label with a semantically identical head word.…”