Convergence in Crossover Service 9811988439, 9789811988431

Citation preview

Advanced Topics in Science and Technology in China

Jianwei Yin · Bing Li · Zhongjie Wang · Shuiguang Deng Editors

Convergence in Crossover Service

Advanced Topics in Science and Technology in China Volume 68

Zhejiang University is one of the leading universities in China. In Advanced Topics in Science and Technology in China, Zhejiang University Press and Springer jointly publish monographs by Chinese scholars and professors, as well as invited authors and editors from abroad who are outstanding experts and scholars in their fields. This series will be of interest to researchers, lecturers, and graduate students alike. Advanced Topics in Science and Technology in China aims to present the latest and most cutting-edge theories, techniques, and methodologies in various research areas in China. It covers all disciplines in the fields of natural science and technology, including but not limited to, computer science, materials science, the life sciences, engineering, environmental sciences, mathematics, and physics. This book series is indexed by both the Scopus and Compendex databases. If you are interested in publishing your book in the series, please contact Violetta Xu (Email: [email protected]) and Mengchu Huang (Email: mengchu. [email protected]).

Jianwei Yin · Bing Li · Zhongjie Wang · Shuiguang Deng Editors

Convergence in Crossover Service

Editors Jianwei Yin Zhejiang University Hangzhou, China

Bing Li Wuhan University Wuhan, China

Zhongjie Wang Harbin Institute of Technology Harbin, China

Shuiguang Deng Zhejiang University Hangzhou, China

ISSN 1995-6819 ISSN 1995-6827 (electronic) Advanced Topics in Science and Technology in China ISBN 978-981-19-8843-1 ISBN 978-981-19-8844-8 (eBook) https://doi.org/10.1007/978-981-19-8844-8 Jointly published with Zhejiang University Press The print edition is not for sale in China (Mainland). Customers from China (Mainland) please order the print book from: Zhejiang University Press. © Zhejiang University Press 2023 This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether the whole or part of the material is concerned, specifically the rights of reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publishers, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publishers nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publishers remain neutral with regard to jurisdictional claims in published maps and institutional affiliations. This Springer imprint is published by the registered company Springer Nature Singapore Pte Ltd. The registered company address is: 152 Beach Road, #21-01/04 Gateway East, Singapore 189721, Singapore

Preface

The world is borderless; however, the limited cognition and capabilities of human beings have led to various types of traditional boundaries. Recently, the development and application of new-generation information technology have significantly enhanced cognitions and capabilities. It has also redefined human cognitive boundaries. Crossover breaks the original boundaries and obtains the perception and collaboration within and outside the boundaries through cross-organizational business process reconstruction that improves the efficiency of social production and daily life. In the crossover process, services from different industries, organizations, and value chains are deeply converged. These services provide users with high-quality and high-value crossover services. Crossover service is a new mode of the modern service industry (MSI), enterprise management, a scenario of information technology application in MSI, and a new direction of service computing research with the characteristics of 3C (crossover, convergence, and complex). The key to implementing crossover service is convergence of multiple dimensions, including pattern, requirement design, runtime environment, quality, and value. In pattern convergence, it is necessary to obtain deep convergence of service patterns from different participants, resolve pattern conflicts and achieve a win-win situation in addition to data convergence, processes, and services in the service ecosystem. During the requirement analysis and convergence design, crossover scenarios cross multiple service systems, and service-design methods are complex and dynamic. Thus, convergence requires different service-design procedures. In runtime environment convergence, services run in open, heterogeneous, and dynamic environments to form complex service networks, which should shield heterogeneous environments and provide a transparent and virtual convergence environment. In the quality-convergence stage, services cross the boundaries of time, space, and domain with different qualities and high variability in the evaluation, which requires a multidimensional attribute convergence of service quality. Value convergence maximizes the value of each party, but there are explicit or potential value conflicts among service participants that require trade-offs. Therefore, based on our current knowledge, this book is the first to focus on convergence in crossover services to provide a comprehensive introduction, the definition of concepts, opportunities, challenges, v

vi

Preface

and discussion, including pattern modeling and computing, requirements analysis, design, infrastructure, optimization, and platform. Ultimately, research on crossover phenomena, crossover services, and convergence problems can further improve its applications in industry and our daily lives. In this book, Chapter “Crossover Service: A Brief Overview” and “Crossover Service Infrastructure: Service Network” were written by Dr. Shengye Pang and Bangpeng Zheng, Prof. Jianwei Yin and Shuiguang Deng. Chapter “Crossover Service Pattern: Modeling and Computing” and “Crossover Service Platform: Scenarios and Applications” were written by Dr. Meng Xi and Jintao Chen, Prof. Jianwei Yin and Shuiguang Deng. Chapter “Crossover Service Requirements: Analysis and Design” was written by Dr. Yu Qiao, Lecturer Zhengli Liu, Associate Professor Jian Wang, and Prof. Bing Li. Chapter “Crossover Service Optimization: Value and Quality” was written by Dr. Min Li, Associate Professor Zhiying Tu, and Prof. Zhongjie Wang. The whole book was finalized by Prof. Jianwei Yin, Bing Li, Zhongjie Wang, and Shuiguang Deng. The work in this book was partially supported by the National Natural Science Foundation of China (No. 61825205) and the National Key Research and Development Program of China (No. 2017YFB1400600). Because of our limited knowledge, errors and defects in this book are inevitable. Hence, we welcome comments and suggestions from our dear readers. Hangzhou, China June 2022

Jianwei Yin Bing Li Zhongjie Wang Shuiguang Deng

Contents

Crossover Service: A Brief Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jianwei Yin, Bangpeng Zheng, and Shengye Pang 1 Emergence and Development of Crossover . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Origin of Crossover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Why Crossover? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Crossover Phenomenon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Crossover Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Modern Service Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Concept of Crossover Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Typical Crossover Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Convergence Perspective of Crossover Service . . . . . . . . . . . . . . . . . . . . . . 4 Main Content of This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Crossover Service Pattern: Modeling and Computing . . . . . . . . . . . . . . . . . Jintao Chen, Meng Xi, Jianwei Yin, and Shuiguang Deng 1 Crossover Service Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Service Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Computational Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Crossover Service Pattern Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Definition of Service Pattern Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Perspectives of Service Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Comparison and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Crossover Service Pattern Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Simulation-Oriented Model Extension . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Process Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Crossover Service Pattern Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Evaluation Metrics of Service Pattern . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Pattern Entropy and Normalized Expenditure . . . . . . . . . . . . . . . . . . . 4.3 Data-Driven Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2 2 3 5 6 6 8 9 12 27 28 29 30 30 32 33 34 34 38 40 40 44 45 47 47 50 52

vii

viii

Contents

5 Crossover Service Pattern Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Rule-Based Service Pattern-Convergence Framework . . . . . . . . . . . . 5.2 Experiment and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57 58 61 65 66

Crossover Service Requirements: Analysis and Design . . . . . . . . . . . . . . . . 67 Yu Qiao, Zhengli Liu, Jian Wang, and Bing Li 1 Metamodel for Crossover Service Requirements Modeling . . . . . . . . . . . . 68 2 Convergence Analysis of Service Requirements . . . . . . . . . . . . . . . . . . . . . 74 2.1 Goal Convergence of Crossover Services . . . . . . . . . . . . . . . . . . . . . . 74 2.2 Process Convergence of Crossover Services . . . . . . . . . . . . . . . . . . . . 80 3 Crossover Service Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 3.1 Design Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.2 Transformation from BPMN Models to UML SDs . . . . . . . . . . . . . . 92 3.3 Transformation from UML SDs to Microservice Design . . . . . . . . . 93 3.4 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4 Requirement-Evolution Analysis of Service Ecosystems . . . . . . . . . . . . . . 95 4.1 Evolution Patterns of Service Convergence . . . . . . . . . . . . . . . . . . . . . 96 4.2 Ecological Evolution Analysis of Service Convergence . . . . . . . . . . 98 4.3 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Crossover Service Infrastructure: Service Network . . . . . . . . . . . . . . . . . . . Shengye Pang, Bangpeng Zheng, Jianwei Yin, and Shuiguang Deng 1 Service Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Service Network Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Core Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Service Wrapper and Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Web Service Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 IoT Service Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Service Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Service Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Service Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Service Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Dynamic Service Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

109 110 110 114 116 118 118 119 122 125 126 130 134 138 144 145

Contents

ix

Crossover Service Optimization: Value and Quality . . . . . . . . . . . . . . . . . . . Min Li, Zhiying Tu, and Zhongjie Wang 1 Service Value and Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Value and Quality Modeling Framework . . . . . . . . . . . . . . . . . . . . . . . 1.2 Collaborative Modeling Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Value/Quality Alignment and Conflict Optimization . . . . . . . . . . . . . . . . . . 2.1 Value/Quality Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Conflict Detection, Measurement, and Resolution . . . . . . . . . . . . . . . 3 Value/Quality Negotiation and Configuration Optimization . . . . . . . . . . . . 3.1 VQD/QCD Two-Stage Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Multi-thread Auto-negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Value/Quality Perception and Continual Optimization . . . . . . . . . . . . . . . . 4.1 Social Media Oriented Value/Quality Perception . . . . . . . . . . . . . . . . 4.2 Business Execution Oriented Value/Quality Perception . . . . . . . . . . . 4.3 Root-Cause Analysis and Fine Tuning . . . . . . . . . . . . . . . . . . . . . . . . . 5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

147

Crossover Service Platform: Scenarios and Applications . . . . . . . . . . . . . . Meng Xi, Jintao Chen, Jianwei Yin, and Shuiguang Deng 1 Architecture and Components of Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Service Pattern Computation and Analysis Tool . . . . . . . . . . . . . . . . . 1.2 Crossover Service Requirement Analysis and Design Tool . . . . . . . . 1.3 Service Network System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Service Quality/Value Optimization Tool . . . . . . . . . . . . . . . . . . . . . . 2 Integrated Case Study of E-Commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Pattern Analysis and Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Requirement Analysis and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Network Environment Convergence and Reconfiguration . . . . . . . . . 2.4 Quality and Value Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

193

149 149 154 157 157 163 169 170 175 180 181 183 187 188 190

194 195 198 200 201 204 205 207 208 209 212

Crossover Service: A Brief Overview Jianwei Yin, Bangpeng Zheng, and Shengye Pang

Abstract With the development of crossover in the modern service industry (MSI), various traditional boundaries have been broken, and the cross-integration of services has led to the need for crossover services. A crossover service is the deep convergence and model innovation of services that cross the boundaries of different industries, organizations, and value chains, aiming to provide users with high quality and high value services. The key to achieving crossover service is convergence, which includes the deep multidimensional convergence of patterns, requirement design, runtime environment, quality, and value. Keywords Crossover · Crossover service · Crossover convergence Although the world is inherently borderless, the limited cognition and capability of human beings has resulted in various traditional boundaries. These boundaries have been redefined through the development and application of new generations of information technology (IT). Crossover is an important innovative strategy for modern firms to expand their products, services, and markets. This strategy promotes cooperation across enterprises, fields, and industries, as well as the creation of innovative products, services, markets, and business models. The increasingly prevalent crossover trend combines traditional and modern sensibilities as well as cultural ways and technology. The development of crossover in the modern service industry (MSI) has afforded a highly developed stage based on IT and modern management concepts. The traditional service supply chain can no longer create value efficiently because of various gaps. In the value-innovation process, enterprises are faced with changes in the J. Yin · B. Zheng (B) · S. Pang Zhejiang University, Hangzhou, China e-mail: [email protected] J. Yin e-mail: [email protected] S. Pang e-mail: [email protected] © Zhejiang University Press 2023 J. Yin et al. (eds.), Convergence in Crossover Service, Advanced Topics in Science and Technology in China 68, https://doi.org/10.1007/978-981-19-8844-8_1

1

2

J. Yin et al.

ecology from single value to mutual win–win, the environment from single organization to mutual collaboration, and methods from single pattern to online/offline. This transition has led to the need for crossover services. A crossover service is an innovation process that enables enterprises to provide users with creative, novel, and cross-domain products/services, which break through the traditional boundaries of enterprises. The crossover service approach has formed gradually with the application of IT in the MSI. It integrates capabilities across multiple boundaries to meet the diverse needs of users and provide more valuable services. This chapter provides an introduction of crossover, crossover services, and typical crossover scenarios, taking Rural Taobao as an example. Further, we discuss the convergent needs and research challenges faced while realizing crossover services.

1 Emergence and Development of Crossover Crossover phenomena are observed in daily life. It is clear that crossover is indispensable because a single domain cannot meet complex requirements, as services across multiple boundaries need to be combined to innovate and create value.

1.1 Origin of Crossover An early example of crossover in the field of Western industrial design is found in the 1950s. Ford, an American car manufacturer, applied a design concept from aircraft to cars. Inspired by the flight of aircraft, wings were spread out like a seagull on the tail of the car. This crossover design aroused the curiosity of the public, and the concept of crossover was thus born. Not long after, the concept of crossover was extended to the field of music. Various styles of music, including modern, traditional, classical, popular, eastern, and western, blended with each other, resulting in songs that appeared on multiple record charts, which track specific musical styles or genres. Thus, crossovers were widely accepted and became popular. In recent years, crossover marketing has developed rapidly. With the development of the economy, it has become difficult to determine to which traditional industry a company belongs owing to the mutual penetration of industries in the market. Crossover cooperation expands brand markets and reduces business risk. Through cooperation in different fields, the reputation and experience of a partner brand in a new region is an intangible asset that can help an enterprise establish its brand image and consumer groups faster. The contrast between different fields also provides a strong visual impact to the brand, eventually forming a marketing effect greater than the sum of its parts. Crossover was originally defined as a path from one side to another; however, crossover is now regarded as an important innovative strategy or method for modern firms to expand their products, services, and markets. It is the result of globalization

Crossover Service: A Brief Overview

3

and is widely used in a wide range of fields across industries. Thus, its definition differs in different fields. In business, crossover describes corporate behaviors that break the inherent boundaries among different industries, introduce ideas and technologies from these industries, and carry out an overall business process (BP) to create value. In art, crossover is defined as the reference and application of different core elements across fields by using creative methods to interpret artwork. Crossover art aims to show creative thinking and achieve more creative art. In education, crossover is the breaking of boundaries between different disciplines through convergent knowledge, through which students are able to combine multiple disciplines to pursue different ways of thinking about the same problem or subject. Crossover remains a vague concept, as it is widely used in different fields. Crossover is not only a kind of behavior, but also a way of thinking. It exists in the leap from one field to another, the conversion from one method to another, and the sublimation of one thought to another. It breaks traditional boundaries to address existing issues.

1.2 Why Crossover? Crossover is the process of generating new products, fields, attitudes, and ideas through the cross collision of professions, fields, concepts and ideologies. There are several causes of crossover: (1) Ideology: Crossover thinking emerged with ancient philosophy. By the time of the European Renaissance, from the 14th to the seventeenth centuries, its main ideas had been widely accepted and applied in many fields. The concept of crossover created a huge innovation in the politics, culture, economy, and thought of the time, which was a major turning point in the history of human civilization. Thinking was liberated from the thousands of years of theological shackles, as the knowledge of various fields was combined and connected to reimagine our understanding of the world. The emergence and popularity of crossover is not accidental. Crossover arouses people’s innovative consciousness by breaking through conventional thought patterns. (2) Culture: With increasing globalization, the cultures of various countries are integrating. This influence is seen as a homogenizing trend that will eventually make human experience everywhere essentially the same. Propelled by technological development, time and space are no longer obstacles and information exchange has become faster and more convenient. Cultures from different regions collide in the exchange, inspiring people with creative talents to continuously pursue new cultural innovations that reflect the progress and development of society.

4

J. Yin et al.

(3) Technology: The current generation of IT, which includes cloud computing, the Internet of Things (IoT), mobile Internet, and artificial intelligence, interconnects everything, profoundly altering information generation and processing. These changes not only promote the cross-domain collaboration of organizations globally but also lead to profound changes in social production and lifestyles. Limitations in the traditional service supply chain result in decreased value creation, and enterprises are faced with the need for new ecologies and methodologies. These challenges are resolved using crossover. (4) Demand: American psychologist Abraham Maslow theorized that human decision making is undergirded by a hierarchy of psychological needs [1]. Crossover is an effective approach to fulfill these needs. With the increasing expansion of material and spiritual needs, increasingly varied commodities can better meet the needs of consumers. In the field of spiritual consumption and commodity sales, crossover products undoubtedly have a wider customer base and innovative value. Crossover promotes cooperation among enterprises, fields, and industries, as well as the creation of innovative products, services, markets, and business models. Crossover has become an increasingly prevalent trend as it bridges tradition and modernity, the East and the West, and culture and technology. Thus, it has become difficult to judge to which traditional industry a company belongs. More and more industries today have evolved into combinations of different industries. Crossover not only promotes resource integration and value creation, but also brings us more valuable ways of thinking. From artistic works to digital products and from commercial markets to academic research, the functions and characteristics of a given field have become more abundant and diversified as a result of crossover. Everything changes from the perspective of crossover. Traditional boundaries are increasingly blurred by crossover, that is, by considering design from the perspective of crossover countries, emotions from the perspective of crossover theories, and market behavior from the perspective of crossover fields. Therefore, crossover has become a trend in theoretical research to bring more possibilities for innovation. The role of crossover in various fields effects new changes and is highly significant. The main impacts are detailed below. (1) New products: The emergence of novel products strongly impacts people and brings a sense of urgency to competitors. Crossover provides a method for companies to develop new products through the combination of cross-field advantages. (2) New fields: The penetration of crossover causes participants to pay more attention to expansion of the intersection of different fields, which is an important area of future growth. The scope of the field itself has been expanded, and potential space for further development within the field has been found. (3) New thinking: Crossover enables a variety of creative solutions and novel ways of thinking. The concept of crossover provides an opportunity to refine classical innovative methods and to develop creative methods for future activities.

Crossover Service: A Brief Overview

5

1.3 Crossover Phenomenon Crossover is not only a reemergence of a classic form of thinking and cooperation, but also a modern trend of cross-field cooperation entailing the intersection and integration of elements in different fields. Crossover has been used in many fields and is becoming increasingly influential. . Crossover Marketing Crossover marketing is a cutting-edge marketing method involving the integration and mutual infiltration of originally irrelevant elements according to the commonalities and connections between consumers in different industries, products, and preferences. This process demonstrates a new attitude toward life and aesthetics to win the favor of the target consumers, enabling brands to maximize marketing via cross-border cooperation. In the new era of increasingly fierce market competition, cross-industry penetration and integration have made crossover marketing an important means of brand development. In 2019, Canadian cosmetics brand M.A.C. partnered with Chinese mobile game Honor of Kings to introduce 5 limited-edition lipsticks featuring the game’s most popular characters. This combination of products was selected because the category is readily accepted by the public in the local Chinese market, and the lipstick is more compatible with the personality and characteristics of the female characters in the game. The ability to wear the same lipstick colors as their favorite characters was very exciting and appealing to consumers. This cross-industry collaboration achieved tremendous success, with over 14,000 preorders across M.A.C.’s WeChat miniprogram, Tmall, and the official website. All of the lipsticks were sold out within 24 h of the campaign launch. The crossover collaboration between the cosmetics and mobile gaming industries was a rather bold approach. . Crossover Vehicle A crossover vehicle is a type of automobile similar to a sport utility vehicle (SUV) built with unibody construction. The term originated in North America. A crossover vehicle is based on the platform of a passenger vehicle, as opposed to that of a pickup truck. For this reason, a crossover vehicle is also called a car-based SUV. Crossover cars have become increasingly popular worldwide since the early 2010s. Chrysler was one of the first car companies to propose and advocate the concept of crossovers globally. The Journey is a midsize crossover SUV manufactured and marketed by Chrysler’s Dodge brand that employs a unibody construction, meaning that the underlying body architecture and frame are a single unit, similar to that of a passenger vehicle. The unibody design is lighter than the more rugged body-onframe construction used in traditional SUVs. The benefits of this design include more interior space for both passengers and cargo, greater fuel economy, and superior ride and handling qualities on paved roads.

6

J. Yin et al.

. Crossover Health Crossover health typically describes offshoots of offline medical organizations and the combination of the internet and healthcare. Online medical treatment mainly consists of four types of services: online consultation and treatment, online diagnosis, follow-up treatment, and health management. At present, internet hospitals have two main operation modes: internet hospitals as a part of offline medical institutions, and independent internet hospitals affiliated with medical institutions. The first internet hospital in China was established in 2015 in Wuzhen, Zhejiang province by the digital medical service platform WeDoctor. The hospital connects well-known doctors with patients all over the nation through its app and website. After talking with doctors via video chat, an electronic patient record is saved in the system. The patient can choose a doctor at home, receive a treatment protocol after remote consultation, and pay their bills online.

2 Crossover Service The development of the MSI, which relies on crossover services, is highly significant to promote the global economy, accelerate social progress, and build an innovationoriented and harmonious society.

2.1 Modern Service Industry The MSI is information- and knowledge-intensive based on IT and modern management philosophy that emerges when industrialization reaches an advanced level. It comprises an upgraded traditional service industry and emerging service industry. The MSI has increased its share in the gross domestic product (GDP) and become a critical criterion for both domestic and global economic development. MSI development has three basic characteristics: Triple-High, Triple-New, and Triple-Little. Triple-High means high human capital, technology, and added values; Triple-New means new technologies, business models, and approaches; and TripleLittle means little area, cost, and pollution. Alternatively, the MSI can also be categorized into four classes based on service sectors: (1) basic services, which include communication and information services; (2) manufacturing and market services, which include finance, logistics, e-commerce, agricultural support, intermediary, and consulting services; (3) personal consumption services, which include education, healthcare, hospitality, entertainment, tourism, real estate, and retail; and (4) public services, which include government public administration services, compulsory education, public health, medical treatment, and public information services.

Crossover Service: A Brief Overview

7

The evolution of the MSI can be separated into four stages. From the 1930s to 1950s, business, transportation, and communication rapidly developed. From the 1950s to 1990s, finance, insurance, and business services enhanced the service function of secondary industries. In the 1990s, e-commerce and modern logistics expanded quickly, and through 1990s into the twenty-first century, information and communication technology facilitated the explosive development of the MSI. Note that in the 1960s and 1970s, the developed world shifted its focus from capitalintensive industries to knowledge- and technology-intensive industries. In the 1980s, the developed world extensively built high-tech industries and transformed conventional industries. Since the 1990s, the developed world has gained a strong foothold at the top of the industry value chain. With the shift from an industry-based economy to a service-based economy, the globalization and professional work division have further promoted MSI development. Statistics from the World Bank1 indicate that the service industry in developed countries accounts for approximately 70% of their GDP; the MSI has accomplished a production value of over 50% of the service industries in total and facilitated more integrated development of the primary, secondary and tertiary industries [2]. The MSI and traditional industries have been increasingly integrated, which helps upgrade the latter. Emerging service industries, including the internet-based e-commerce and content services, have become a leading engine for the global economy; the MSI is becoming a core link of the modern industrial system. Countries at all levels of industrialization and income can exploit transformative opportunities from the service industry. In the past three decades, the service sector has grown faster than manufacturing in many developing economies. By 2019, services accounted for 55% of the GDP and 45% of employment in developing economies. In developed economies, services account for an even larger share of economic growth—75% on average. A few low- and middle-income countries were among the top 10 global exporters of services between 2005 and 2017 [3]. IT, professional, scientific, and technical services are growing in importance within the service industry. Economic transformations in the MSI offer new opportunities for scale, innovation, and spillover effects similar in scope to those that increased the productivity of manufacturing in the past. Remote delivery, branching, and franchising enable service providers to tap larger markets, and providers who offer services digitally are no longer restricted to face-to-face engagements with their customers. Digital technologies are improving BPs, introducing new product features, and creating new markets. Far more research and development are now being performed in services than in industry: big data is enabling the improvement of transportation systems as well as spurring retail outlets to improve their offerings. The characteristics of crossover and convergence have become an important trend, requirement, and feature of innovative development of the MSI, which highlights the need for crossover service.

1

http://data.worldbank.org/indicator

8

J. Yin et al.

2.2 Concept of Crossover Service With the development of crossover, the integration of the MSI and the primary sector and the secondary sector is accelerating. Various traditional boundaries have been broken, and the cross-integration of services has led to the need for crossover services. A crossover service is the deep convergence and model innovation of services that cross the boundaries of different industries, organizations and value chains, aiming to provide users with high quality and high value services. Crossover service is a new style of the MSI, and a new form of modern enterprise management, and a new scenario for the application of IT in the MSI, and a new trend of service computing. The essence of crossover services lies in the deep convergence of services across different industries and organizations, forming a complex service network and generating a large service ecosystem. In this book, we generally define crossover service as an innovation process for enterprises to provide users with creative, novel, and cross-domain products and services that break through the traditional boundaries of enterprises. The crossover service can be understood from both broad and narrow perspectives. From the broad perspective, it is a service that crosses different boundaries, such as different organizations, different domains, and different industries. From the narrow perspective, a crossover service entails all the necessary processes and activities that support an enterprise to design, implement, produce, and manage new products or services targeting a completely new market or industry. Crossover service is a new style formed gradually with the application of IT in the MSI. It integrates capabilities across multiple boundaries to meet the diverse needs of users and provide more valuable services. The emergence of new technologies, such as cloud computing, mobile Internet, and artificial intelligence, has blurred the boundaries of various enterprises, industries, and fields and promoted the rise of crossover services. Crossover services have “3C” characteristics, namely, crossover, convergence, and complexity. Crossover: Crossover is the basic characteristic of crossover services, which are provided across different business areas, different industries and different industrial domains. Intangible products formed or derived from crossover services are always cross-domain. For example, Internet hospitals provide online appointments, online consultation, and other Internet services across organizational and geographical boundaries. For example, the crossover e-commerce Rural Taobao provides agricultural products transactions across the boundaries of finance, e-commerce, and logistics.

Crossover Service: A Brief Overview

9

Convergence: Convergence is the fundamental attribute for which modern enterprises provide crossover services. Convergence occurs among different industries and gradually forms a new crossover industry through interaction and mutual infiltration. Convergence is a dynamic development process comprising technological, product, service, enterprise, and market convergence. Intangible products formed or derived from crossover services are the result of convergence. For example, the health code is an innovative service provided by Alibaba Group that integrates capabilities in multiple fields, such as public services, mobile services, and big data. Complexity: Compared with traditional services, crossover services are more complicated in the innovation, development, and operation process. It is difficult for the providers of crossover services to not only cross the boundaries of different industries and integrate all kinds of resources into industries or areas with which they are not familiar, but also conduct a series of innovative activities, such as service innovation and business pattern design, by combining their resources, market, and technology. Furthermore, those enterprises already existing in the market have advantages in marketing, technology, and services, which brings more risks and challenges to the crossover service providers. For example, Rural Taobao has served more than 7,000 villages in 2020 while covering the retail, finance, agriculture, logistics, and warehouse industries [4].

2.3 Typical Crossover Scenario With the rapid development of e-commerce, the growth of traditional e-commerce users has reached a bottleneck, and major e-commerce giants have begun to focus on the vast market of rural areas. However, the shortcomings of poor network coverage in rural areas, relatively backward logistics systems, and farmers’ low ability to apply the network have limited the development of rural e-commerce. In response to these problems, Alibaba launched the Rural Taobao project based on an e-commerce platform to give full play to the advantages of e-commerce by building county– village service networks, thereby breaking through the bottleneck of logistics and information flow and realizing the two-way flow of online goods to the countryside and agricultural products to the city. Rural Taobao is a typical crossover scenario crossing the boundaries of domain, system, identity, and technique to achieve the multidimensional convergence of pattern, design, runtime environment, quality, and value. . Crossing domain boundaries The Rural Taobao crossover scenario involves eight domains, namely, agency services, agriculture, agricultural and sideline food processing, warehousing, postal services, manufacturing, retail, and finance, with nearly 25 types of service participants working together to achieve upward mobility of agricultural products and downward mobility of consumer goods, as shown in Fig. 1.

10

J. Yin et al.

Fig. 1 Rural Taobao service crossing domain boundaries

. Crossing system boundaries Crossover in the Rural Taobao system is mainly reflected in the information interactions of five subsystems: payment, Rural Taobao, the courier company, the logistics company, and e-commerce. The traditional and rural e-commerce systems share merchant, commodity, and user data. The financial payment system is docked with the rural e-commerce system to complete the interaction between order settlement and payment information and jointly complete the payment function. The interaction between the systems of Rural Taobao, logistics companies, and courier companies is mainly reflected in the interaction between delivery and status information, and the parcel status is kept synchronized between them, as shown in Fig. 2. . Crossing role boundaries In the Rural Taobao scenario, a participant can assume different roles and functions at a certain time, thus reflecting the cross-role features of the crossover scenario. As a participant who interacts directly with villagers, the rural partner has four roles: purchasing agent, receiving agent, selling agent, and sending agent, and can switch between different service scenarios. In the scenario where online goods are sent to the countryside, the rural partner mainly embodies the purchasing and receiving roles; in the scenario sending agricultural products to the city, the rural partner mainly realizes the selling and distributing roles, as shown in Fig. 3. . Crossing technique boundaries In the upstream chain of agricultural products, Rural Taobao has made a bold attempt to use e-commerce data to support the planting and harvesting of agricultural products. While traditional e-commerce is only responsible for online sales, Rural Taobao

Crossover Service: A Brief Overview

11

Fig. 2 Rural Taobao service crossing the boundary of system

Fig. 3 Rural Taobao service crossing role boundaries

not only provides a platform for online shopping, but also makes full use of online sales data to explore special varieties, planting areas, and market preferences and demand. It also helps villagers improve production and optimize the quality of agricultural products through the participation of agricultural experts. However, there is still distance between the primary agricultural products and commodities, and there is a lack of brand-operation knowledge among farmers. Rural Taobao can be of great help to villagers in creating regional brand characteristics, as shown in Fig. 4.

12

J. Yin et al.

Fig. 4 Rural Taobao service crossing technique boundaries

3 Convergence Perspective of Crossover Service The key to achieving crossover service is convergence, which includes the deep multidimensional convergence of patterns, requirement design, runtime environment, quality, and value. In pattern convergence, it is necessary not only to converge data, processes, and services in the service ecosystem, but also to realize the deep convergence of service patterns from different participants, resolve pattern conflicts, and achieve a win–win situation. During requirement analysis and convergence design, crossover scenarios cross multiple service systems, the service-design methods are complex and dynamic, and different service-design methods need to achieve convergence. In runtime environment convergence, services run in open, dynamic and heterogeneous environments to form complex service networks, which need to shield heterogeneous environments and provide a transparent and virtual convergence environment. In the quality-convergence stage, services cross the boundaries of time, space, and domain with different qualities and high variability in evaluation, which require multidimensional attribute convergence of service quality. The purpose of value convergence is to maximize the value of each party, but there are often explicit or potential value conflicts among services participants that require trade-offs. . Pattern convergence As an important driving force for the development of the MSI, the service pattern is a service-provision method that supports the realization of business models. It describes end-to-end services provided by service companies, such as methods for industry chain synergy, approaches for service acquisition, and the operation and maintenance system. Moreover, service patterns include various strategies, such as service resource allocation, activity organization, and stakeholder synergy, which guide the design of specific BPs. The simplest atomic service pattern comprises only two entities that interact directly, while complex patterns are obtained by combining multiple atomic service patterns. For example, there are nine participants in the Rural Taobao crossover scenario, namely, the Rural Taobao platform, traditional e-commerce platform,

Crossover Service: A Brief Overview

13

Fig. 5 I2C pattern case

rural partner, logistic company, delivery company, contracted merchants, financial company, promoters, and villagers, which are interconnected and constitute the Rural Taobao service ecology. Typical subpatterns of Rural Taobao include: (1) The information-to-consumer (I2C) pattern with the interaction among promoters, Rural Taobao, and villagers as an example. Through the Rural Taobao platform, promoters recommend products to villagers, constituting a simple service chain in the rural e-commerce ecology (Fig. 5). (2) The business-to-consumer (B2C) pattern with the interaction among the logistic company, Rural Taobao, and villagers as an example. Logistics companies provide delivery services to villagers who place orders or sell agricultural products on the Rural Taobao platform (Fig. 6). (3) The consumer-to-consumer (C2C) pattern with the interaction among villagers, Rural Taobao, and consumers as an example. While the upstream chain sends the agricultural products to the city, the villagers sell them on the Rural Taobao platform. The difference between the C2C and B2C patterns lies mainly in the business nature of the participants (Fig. 7). (4) The online-to-partner (O2P) pattern with the interaction among contracted merchants, Rural Taobao, the logistics company, the rural partner, and villagers as an example. The O2P pattern is a new mobile Internet business pattern targeting the transformation of traditional business models into new business models combining the e-commerce platform, customer experience store, community store, and logistics (Fig. 8).

Fig. 6 B2C pattern case

Fig. 7 C2C pattern case

14

J. Yin et al.

Fig. 8 O2P pattern case

In summary, based on the Rural Taobao service pattern, the service networks at the village and county levels have been built to bring online goods to the countryside and agricultural products to the city, thus improving farmers’ income levels and quality of life. Compared with the traditional e-commerce service pattern, the innovation and complexity of the Rural Taobao service pattern lie in: (1) New audiences: Traditional e-commerce is mainly oriented toward urban consumers, while rural e-commerce is mainly focused on the needs of rural users. However, as rural areas have become a potential development area for e-commerce, the different consumption habits and spending ability of rural users pose a significant challenge to the implementation and operation of rural e-commerce. (2) More complex pattern structure: A variety of simple service patterns converge to form the Rural Taobao pattern, and the interaction between various participants creates a mesh structure. With the addition of the new identity, the traditional transaction chain is reconstructed and the service structure becomes more complex. (3) More complex service pattern synergy: The simple service pattern of Rural Taobao may contain multiple participants, and any participant may be involved in multiple service patterns, which inevitably generates conflicts and contradictions. For example, the e-commerce promoters and rural partner both recommend goods to obtain a commission, creating a conflict of value between them. Therefore, the synergistic strategy required to achieve a balance among various conflicts at the pattern level in rural e-commerce is complicated. Prior to crossover, individual participants have their own service patterns. To break through these patterns and achieve crossover convergence, we must first resolve pattern conflicts to find an optimal situation for multiple participants. The deep convergence of multiple patterns can improve service efficiency, reduce costs, and increase the competitiveness of crossover participants, while a simple combination can lead to many problems, such as low resource utilization and collaboration efficiency. However, there is still a lack of theoretical understanding and practical methods. Moreover, the convergence of crossover service patterns faces the problems of inefficiency and disorder. The challenges of service pattern convergence are summarized below. (1) Lack of theoretical support system: The crossover convergence of services has led to new trends of the changes in service providers, consumers, processes,

Crossover Service: A Brief Overview

15

goals, and values. The traditional triangular service pattern comprising a service provider and service consumer, as well as the symbiotic goals between them, can hardly explain the full connotation and characteristics of the new service. Therefore, it is necessary to refine the essential features and core elements of the traditional triangular service pattern and propose a service pattern model that support complex crossover scenarios, along with its descriptive language. (2) Lack of model-driven calculation and evaluation methods: Service patterns arrange and configure business activities, processes, data, resources, markets, users, and other elements for specific service goals to achieve value proposition, creation, delivery, and acquisition. Different service patterns have different market vitality, and individual service patterns often show varying performance under different environments. Although service patterns are an important means to achieve corporate innovation, there remains a lack of effective methods to evaluate the value generated. Therefore, it is necessary to study the calculation method and evaluation system of crossover service patterns. (3) Lack of crossover service pattern-oriented computing tools: Relevant tools and systems need to be developed for service pattern visualization modeling, service pattern operation simulation, service pattern evaluation, etc. The usability and effectiveness of these tools could be verified by application in specific scenarios. . Requirement and design convergence Crossover services are usually formed through the integration of services across multiple fields. In this process, various organizations, stakeholders, value chains, platforms, services, and other entities gradually evolve into a service ecosystem through cooperation and competition. This ecosystem involves the integration of business models, technological systems, and value goals, and its characteristics should be considered in the requirement analysis and design of crossover services. These characteristics include openness, diversity, interaction, self-organization, and evolution. In the service model of the rural e-commerce business scenario, the requirements of each participant are further refined based on analysis of the service pattern, and the interaction among different systems in each organization are modeled. In the development of rural e-commerce, there are tremendous obstacles, such as poor infrastructure and difficult logistics in remote or unreachable areas. In the face of such challenges, it is difficult for the traditional e-commerce ecology to extend business to rural areas. To meet the shopping needs of villagers in rural areas, rural e-commerce platforms should extend the service boundaries of e-commerce fields as well as recruit and integrate rural partners into the rural e-commerce ecology. The ecosystem involves the collaboration of multiple industry organizations, such as e-commerce, financial payment, and logistics companies, that actively cooperate to meet the shopping needs of villagers in rural areas. In the rural e-commerce ecology, stakeholders have prominent crossover characteristics. For example, villagers are shoppers on e-commerce platforms, but they are also consignees to logistics companies and policyholders to

16

J. Yin et al.

insurance companies. Hence, the rural e-commerce ecosystem is the result of the mutual infiltration, integration, and coexistence of multiple industries and services. To clearly describe the system behavior of rural e-commerce crossover services, we first apply use-case diagrams to describe the interaction between the rural e-commerce crossover services and their participants. Then, we use an activity diagram to clarify the responsibilities of each stakeholder and their interactions with other stakeholders in the scenario. Finally, we use the interface-interaction diagram to describe the data-exchange relationship among different stakeholders and organizations and thus map the business requirements to software requirements. According to the rural e-commerce scenario, we construct a use-case diagram to describe the interaction between rural e-commerce crossover services and their participants, as shown in Fig. 9. In the rural e-commerce scenario, the participants include villagers, rural partners, contract merchants, rural e-commerce administrators, village juniors, contract merchants, county warehouse couriers, and couriers with the courier company. Rural e-commerce administrators are responsible for managing rural e-commerce platforms, which mainly involve five use cases: handling disputes and reviewing merchants, rural partner information, commodities, and village station information. Villagers mainly buys goods on rural e-commerce platforms under six use cases: managing orders, querying postal information, searching for products, browsing product details, managing personal information, and managing shopping carts. In addition, a rural partner also has three unique use cases: ordering on behalf of the village, contacting villagers, and receiving goods on behalf of the village. All couriers have a common use case of entering postal information. Couriers in county warehouses have only one unique use case: transit. In contrast, the courier company has three unique use cases: delivering goods, transporting goods, and collecting goods. Among these, transportation is further defined according to whether the goods are distributed through rural e-commerce and includes an extended use case: routine logistics distribution. After analyzing the interaction between the stakeholders and the rural e-commerce crossover services through the use-case diagram, we use an activity diagram to clarify the activities of the process link, the person in charge of it, and the organization or department to which it belongs. Figure 10 is an activity diagram of the rural e-commerce crossover service showing that the transaction scenario of rural e-commerce involves many roles that undertake different tasks. The transaction link is long and has obvious crossover, fusion, and complexity characteristics. The rural e-commerce scenario involves nine entities, namely, villagers, rural partners, rural e-commerce platforms, e-commerce platforms, logistics platforms, third-party (TP) providers, logistics companies, financial payment platforms, and contracted merchants. Among them, villagers are the core of the shopping process, and they can shop on their own or entrust village partners to buy on their behalf. The main responsibilities of rural partners are to recommend and collect commodities for the villagers. The rural e-commerce platform mainly provides a shopping platform for villagers and determines whether it can provide routine logistics services according to the village location. The main responsibility of the e-commerce platform is to supply the rural e-commerce platform and enrich the available commodity types. The

Crossover Service: A Brief Overview

Fig. 9 Use-case diagram of rural e-commerce crossover services

Fig. 10 Activity diagram of rural e-commerce crossover service

17

18

J. Yin et al.

logistics company is mainly responsible for delivering goods and judging whether to utilize the county warehouse according to whether the user selects the village station. When routine distribution is required, the goods must be delivered to the county warehouse, and then the logistics platform entrusts a TP provider to deliver goods to the rural partners. Afterward, the goods are delivered to the villagers by the second village junior. Finally, the financial payment platform provides the users with convenient online payment functions. Requirement analysis is used to map business requirements to software requirements in order to guide subsequent software development. The crossover service of rural e-commerce involves the coordination of different business systems among multiple organizations. Therefore, it is necessary to model the system interaction and the transfer of interface parameters to guide subsequent development and design. Figure 11 depicts the interface interaction among different organizations and systems in the crossover scenario of rural e-commerce. This scenario involves the coordination of multiple systems, such as a rural e-commerce system, rural e-commerce logistics system, e-commerce platform system, logistics platform logistics system, financial payment platform system, and logistics company system. After the user places an order, the rural e-commerce system needs to call the payment interface of the financial payment platform to enable the user to pay for the product. During this process, parameters, such as the order amount and product information, must be transmitted. After the user completes the payment, the financial payment platform returns a “successful payment” message to the rural e-commerce business. After the merchant ships the goods, the logistics company returns the logistics order number to the rural e-commerce business and informs the user. The user can then query the logistics details. The rural e-commerce system can also call the interface of the logistics company to query real-time logistics information and display it on the rural e-commerce page. When the goods need to undergo routine logistics distribution and arrive at the county warehouse, the TP company will complete the sorting and delivery process and enter the logistics delivery information into the system. Finally, the rural e-commerce platform will display real-time logistics information to the user. In the scenario analysis, we observe that crossover services usually span multiple industry boundaries, and user requirements are characterized by diverse roles, goals, and variable processes. Meanwhile, the process of crossover service integration in an open environment needs to support cross-domain integration and deep integration of different enterprise businesses, which brings significant challenges to the design of crossover services. The challenges faced in the requirement analysis and design of the crossover service are summarized below. (1) The requirement analysis and design of crossover services need to be carried out from the overall perspective of the ecosystem to address the characteristics of crossover service systems. The service ecosystem is mainly formed through the mutual interaction, restriction, and coevolution of the three subsystems of society, business, and technology. Therefore, a metamodel that offers

Crossover Service: A Brief Overview

19

Fig. 11 Interface-interaction diagram of Rural Taobao cross-service transaction

the modeling elements and their relationships should be constructed from these three ecological perspectives. (2) It is challenging to meet the increasingly complex goals of users in modern society with services from a single domain. Thus, crossover service convergence, which aims to provide deep service integration and innovation across the boundaries of industries, organizations, and value chains, has become an urgent need. Goal convergence is the first step to guiding the process of crossover service convergence. However, crossover service scenarios involve many stakeholders, whose goals in different domains are prone to conflict during the service-convergence process. Therefore, determining how to realize the automatic convergence of goals, support the resolution of goal conflicts, and improve the efficiency of requirement modeling is a significant problem that needs to be solved in crossover service requirement analysis. (3) In BP management, reusing efficient process models or fragments can greatly improve the efficiency and quality of process modeling. To design the integration of crossover services, it is necessary to consider the integration of BPs in different domains in order to realize business integration in other domains or expand the business boundary to other domains. It is necessary to pay attention to both the impact of changes in message flow and the effects of different roles and goals on the convergence of crossover service processes. It is also

20

J. Yin et al.

essential to provide an automation mechanism to map the process model to the corresponding API design. . Runtime environment convergence In the Rural Taobao crossover scenario, inconsistent internet service between rural and urban environments is a problem. Therefore, it is necessary to cross the boundaries of heterogeneous service runtime environments and provide a transparent convergence environment. In traditional BPs, services run on local servers for the entire business under normal operation. There is no need for the services of different businesses to interact; thus, service boundaries exist between businesses. As a crossover scenario, Rural Taobao crosses multiple service domains, breaks boundaries between crossover participants, increases the frequency of service interactions between different businesses, and creates an increasingly obvious trend of openness and interconnection of services. The Rural Taobao crossover scenario generates new service chains by integrating the original service chains of each crossover participant. Figure 12 illustrates the interaction process of different services in the newly generated core service chain for order creation. To resolve the frequent interaction of services between different participants in Rural Taobao, a distributed remote procedure call (RPC) service framework connecting different business systems is adopted to achieve consistent scheduling and operation of services, decouple the dependencies between systems, and unify the publishing/invocation methods of services.

Fig. 12 Order-creation service invocation chain

Crossover Service: A Brief Overview

21

The current service-invocation scenario comprises the following main participants: Service provider: The service provider binds a port, accepts the request, provides the service, and publishes the address to the address server. To guarantee high service availability, the provider is usually deployed as a cluster running in a container in the form of a War package. In the current scenario, the service provider is Rural Taobao. Service customer: The service customer subscribes to the service through the address server and initiates a service invocation based on their address information. In the current scenario, the service customer is a rural partner. Address server: The address server is responsible for providing service providers and customers with a list of all configuration and Diamond servers in the deployment environment. Services access the address server through the domain name, enabling load balancing and high availability of services. Configuration server: The configuration server is mainly responsible for recording all service release and subscription information and pushing this information to the service nodes. The configuration server is long-connected to all service providers and consumers, uses a heartbeat mechanism to monitor the operation of each service node, and pushes an updated list of service providers to service customers in real time. Diamond server: The Diamond server is a unified configuration-management server that provides configuration settings for applications and mainly undertakes rule configuration for security control, routing weights, and QPS thresholds of the service. The current service-invocation scenario contains the following main service activities: Listing configuration servers. When services are deployed on the servers, the service nodes can obtain the available server addresses in the form of domain names. Therefore, the list of configuration and Diamond server IPs is already available on the service node after the container startup is completed. Service registration and publishing. After the list of configuration servers is obtained, the rural e-commerce platform order-creation service sends the service provider information, IP address of the server, and service port to the configuration server to register and publish the service. Service subscription. The service customer’s request information is sent to the configuration server for the service provider. Once the corresponding serviceregistration information is obtained, the IP address and port of the service provider are returned to the node where the service customer is located to complete the service subscription. Rule pushing. Through the rule settings interface provided by the Diamond server, the interface parameters of the service provider and service consumer are pushed to both service participants. Service interactions. When a service invocation is initiated, a service request is sent from the list of service providers stored on the node.

22

J. Yin et al.

Each service participant in the service ecosystem, in addition to managing its own services, needs to invoke the open services of other participants and collaborate to meet complex business requirements. Services across multiple participants invoke each other, forming a complex service network. Crossover services running in the service network show characteristics including high-dimensional heterogeneity, complexity, and dynamics. It is necessary to provide a convergent and transparent environment to ensure the efficient and stable operation of crossover services. Challenges for service runtime environment convergence are summarized below. (1) Openness of services. Before crossover collaboration, the participants are in a more closed operation state and do not cooperate or interact with each other. For example, in e-commerce logistics, the transportation status is usually stored in local or cloud servers. Merchants lack access to this status at any given moment, and thus cannot provide customers with real-time delivery information. Therefore, the primary issue to realize crossover collaboration is determining how to package functional modules or physical equipment operating in isolation in each participant into services for external or designated partners. (2) Service access. As industries upgrade digitally, there will be an increase in services of various types within the network. Currently, most services are deployed on local servers and lack a unified service-registration and management mechanism, thus forming many service silos. Unlike information retrieval, online service retrieval is more difficult to achieve and, in most cases, can only be achieved through offline manual collaboration, which strongly affects the efficiency and quality of crossover service implementation. Therefore, another major challenge is determining how to build a unified service network architecture and realize service access and management. (3) Service dynamic adaptation. The transmission of data usually follows one or more traditional protocols, but the lack of strict standards for the design of services leads to difficulties in the dynamic adaptation of services, as well as challenges to the crossover convergence of services. (4) Service discovery and routing. In a typical service-invocation scenario, both invokers upload their respective service information to the configuration server, and the configuration server subsequently updates the service list to give the service invoker the real-time location of the service provider. With the help of routing server scheduling, the fastest service-routing path can be achieved under the constraint of load balancing, which is essentially a global routing approach. However, as the numbers of services and server accesses continue to grow and the business needs of users become increasingly complex, the global routing approach creates massive congestion and imposes a significant burden on the entire network. Therefore, a more optimized distributed service-routing algorithm is needed to achieve service-routing control and ensure efficient and reliable interaction among crossover services.

Crossover Service: A Brief Overview

23

. Value and quality convergence Rural e-commerce is a classic crossover service scenario. As introduced in Sect. 2.3, this scenario involves multiple participants from different fields. They give full play to their specialties in service value, quality, and capability in specific fields and cooperate with each other to meet the expectations for these qualities overall. Through value and quality convergence among multiple participants, not only can the complex and diverse needs of consumers be met, but the value provided by all parties can be transmitted smoothly and transformed in the entire crossover service. Further, new service value can be created. However, multiple service boundaries, such as industry, technology, and organizational domains, create challenges for multiparticipant value/quality convergence. (1) Heterogeneous multidomain service value–quality–capability (VQC) evaluation system We conducted a detailed survey of rural e-commerce and identified the service VQC indicators prioritized by each participant, main business activities, and value associations with other participants. With the innovative role of village-level service stations within rural e-commerce as an example, Fig. 13 shows the main business functions, service VQC indicators, and value associations with other participants. The villagelevel service stations provide four main operations: agent receipt, purchase, delivery, and sales. Agent receipt means that the end point of village logistics is at the villagelevel service station, where the goods purchased by farmers are kept to be picked up by the villagers themselves. Agent purchase means that village waiters place or combine orders on the platform on behalf of farmers and fill in the necessary commodity specifications and logistics information. Agent delivery means that the agricultural products harvested by farmers are distributed by village-level service stations, and agent sales means that village waiters edit and publish agricultural product information to online stores. During agent receipt and purchase, village waiters can earn commissions, and in the agent delivery and sales, they can earn the price spread. The resources of the village-level service station include the station, village waiters, and basic hardware facilities. The main function of the station is to store goods. To enable villagers to shop and pick up items while also accommodating the order volume of village waiters, a village-level station is generally set up within a range of 5 km, and the distance between two village stations is not less than 3 km. Because the village waiters must collect and purchase goods on behalf of the villagers, access to ecommerce can enable them to better assist the upward movement of agricultural products and obtain more profits. The service quality and value of this model are not significantly different from those of traditional e-commerce, and remain focused on service timeliness, loss-free rate, order volume, and turnover. From this example, we can see that the VQC model of a single service provider is very rich and closely related to other participants. Cross-border services involve many participants, who belong to different service fields, and the evaluation system of

24

J. Yin et al.

Fig. 13 Example of village-level service station VQC evaluation indicators and value associations with other participants

service VQC is heterogeneous. Therefore, the underlying principle of value/quality convergence is service VQC modeling and the alignment of heterogeneous evaluation systems. From this example, we can see that the VQC model of a single service provider is very rich and closely related to other participants. Crossover services involve many participants belonging to different service fields, and the evaluation systems of service VQC are heterogeneous. (2) Multiparticipant complex VQC dependence In rural e-commerce, service participants have complex dependencies on the service value, quality, and capability. These dependencies are the basis for value transmission and transformation, but are also constraints on service value/quality optimization. The service capabilities are measured by agricultural product sales, gross profit margin, and user satisfaction. The e-commerce platform uses its big data mining and analysis capabilities to accurately identify the hot-selling types of agricultural products and user preference attributes (such as diameter, maturity, color, color, sweetness, special nutrient content, etc.) as well as estimate the market demand for the agricultural products and the time period for large-scale procurement. Then, agricultural experts formulate scientific and standardized cultivation plans according to user preference attributes and the agricultural growth environment, provide efficient and accurate technical support and tools, and capture relevant data analysis on the quality and yield of the final agricultural products. Farmers need to operate their farms in accordance with standardized planting techniques to ensure the quality of agricultural products. Agricultural products are unsuitable for sale as commodities immediately after harvest; they must first be processed by agricultural and sideline food processors. Rough processing selects high-quality agricultural products and provides reasonable packaging methods, while fine processing can further improve the taste and nutritional value of agricultural products. Upstream merchants, such as Hema or

Crossover Service: A Brief Overview

25

Fig. 14 Example of service capability dependencies in rural e-commerce

Taoxiangtian, promote and sell agricultural products for special consumer groups; ultimately, fresh and delicious products can be delivered to consumers (Fig. 14). The quality of the agricultural products is key to the service quality in the uplink. High-quality agricultural products need accurate market positioning from rural ecommerce platforms and configuration plans by agricultural experts, which must be executed by farmers. The three parts are interdependent and indispensable. The commercialization of primary agricultural products is realized stepwise during their harvesting, rough processing, fine processing, and compliance. It is necessary to ensure that the agricultural products will not rot and deteriorate during storage and transportation. The agricultural products carefully selected based on the capabilities of the above parties can be delivered fresh to consumers. In the downlink, the service qualities of home appliances before, during, and after sale distinguish rural e-commerce from general retailers. In the presale selection process, rural e-commerce only cooperates with well-known home appliance brands, and selects home appliance categories with different product configurations at different prices. In the sale stage, the offline store of Tmall is used to display the preferred products for consumers to test. If consumers place an order, Tmall Direct Delivery deliver it to their home within 24 h and provide door-to-door installation and power-on trial services. After the sale, orders created at Tmall enjoy a 15-day free replacement, 30-day worry-free returns, and a full-year nationwide warranty service guarantee (Fig. 15). The service value created, transmitted, and added for agricultural products is clearly reflected in the upward link. In the e-commerce platform, the mining of hotselling agricultural products creates data value, the selection and cultivation plans of agricultural experts provide technical value, the farmers’ labor provides production value, and the value of the primary agricultural products as commodities is further increased by rough and fine processing. Promotion through the e-commerce platform also brings brand value to the local agricultural products. Finally, delivery to the home provides consumers with sustenance and the consumers’ loyalty and repurchasing generate economic value, which in turn promotes the widespread planting of agricultural products and increases farmers’ income. Thus, the graph of the entire value transfer network is a circle as long as each party assumes its corresponding service

26

J. Yin et al.

Fig. 15 Example of service quality dependencies in rural e-commerce

responsibilities. In the rural e-commerce scenario, adding the role of a village waiter is convenient to provide more considerate and professional services to the villagers. The most basic value that the village waiter can obtain is the service charge provided by the merchant in the agent receipt and purchase links. If there are planting areas and high-quality agricultural products nearby, village waiters can also use their expertise in e-commerce operations to open online stores, put local agricultural products on the shelves, undertake agent delivery and sales tasks, and collect the difference between the purchase price and the selling price of agricultural products (Fig. 16). There are many problems in the promotion and implementation of rural ecommerce: (1) In the service design stage, crossover services involve numerous service providers with different service capabilities, quality, and value. When forming crossover services, it is necessary to negotiate with many service providers to eliminate ambiguity or conflicts between them, which requires significant manpower and material resources. (2) In the service-implementation stage, there are many uncertain influencing factors in the service industry, especially physical service. It is difficult to ensure that the fixed service model can fully achieve the estimated effect for the specific implementation. An efficient and sensitive abnormality-sensing mechanism and a timely response mechanism for sudden problems are needed, and the original service model must be optimized using the long-term service sensing results. The objective reason for the above two problems is the crossover characteristic of services. Because a single service cannot meet the myriad needs of consumers,

Fig. 16 Example of service value dependencies in rural e-commerce

Crossover Service: A Brief Overview

27

the problem of multiple participants exists. Multiparticipant crossover collaboration inevitably causes inconsistencies and conflicts. The managers of crossover services have realized that crossover convergence can provide better service value and quality. The root cause of these problems is the lack of complete theoretical methods and technical support for service analysis and modeling, service optimization and negotiation, service perception and monitoring, problem tracking, and continuous optimization during the design and implementation of crossover services.

4 Main Content of This Book The crossover service is a new mode of the MSI, a new method for modern enterprise management, a new area of IT application, and a new direction of service computation. Crossover services are characterized by crossover, convergence, and complexity, and their essence lies in the deep convergence of services across industrial and organizational boundaries to form complex service networks and incubate large-scale service ecosystems. The key to achieving crossover service is convergence, which includes the deep multidimensional convergence of patterns, requirement design, runtime environments, quality, and value. Therefore, in this book, we address the main convergence problems in crossover services and introduce related models, theories, technologies, and methods. Specifically, the contents of each chapter are briefly introduced. This chapter introduces the definition, basic characteristics, typical scenario, and research challenges of crossover phenomena and services. Chapter “Crossover Service Pattern: Modeling and Computing” proposes a service pattern model and its description, a method to simulate service patterns, an evaluation system, and a convergence framework to address the modeling and computation problem of crossover service patterns. Chapter “Crossover Service Requirements: Analysis and Design” proposes an ecology-oriented metamodel of crossover service requirements and establishes a requirement-analysis method to address the convergence problem in the design and analysis of crossover service requirements. Chapter “Crossover Service Infrastructure: Service Network” proposes a crossover service network architecture, service packaging and access methods, and management algorithm for service network operation to achieve convergence of the crossover service runtime environment. Chapter “Crossover Service Optimization: Value and Quality” proposes a series of solutions to the value/quality-oriented crossover service-optimization problem, including building a crossover service VQC evaluation system and finishing the mapping, integration, and conflict resolution between multiple domains; monitoring the service value and quality during the running phase and tracking the source of service exceptions; and continuously providing service-improvement programs. Based on the above research achievements, chapter “Crossover Service Platform: Scenarios and Applications” develops a crossover service-convergence design

28

J. Yin et al.

and support system and validates the effectiveness of the system through a typical crossover scenario: Rural Taobao.

References 1. Maslow AH (1943) A theory of human motivation. Psychol Rev 50(4):370–396 2. World Bank (2012) World development indicators 2012. https://elibrary.worldbank.org/doi/abs/ 10.1596/978-0-8213-8985-0 3. United Nations (2019) Effective market access for least developed countries’ services exports: an analysis of the World Trade Organization services waiver for least developed countries. https:// unctad.org/publication/effective-market-access-least-developed-countries-services-exports 4. The Ali Institute (2020) China Taobao Village Report 2020. http://www.aliresearch.com/en/Rep orts/Reportsdetails?articleCode=167153834769125376

Crossover Service Pattern: Modeling and Computing Jintao Chen, Meng Xi, Jianwei Yin, and Shuiguang Deng

Abstract A service pattern is the overall description of a service-coordination mechanism, participant interaction pattern, and data/resource/value-allocation scenario in a business service. For crossover services, service patterns are service-delivery methods that support the realization of business models. Service patterns describe how service enterprises provide services in the industrial chain and the methods of cross-domain participant collaboration, including value acquisition, resource allocation, data transmission, activity organization, and stakeholder collaboration. In short, a service pattern is the implementation of the service business model in the context of the service industry. Crossover service pattern modeling refers to the description of the participants, workflows, data, resources, and value in crossover services. Thus, service pattern computation concerns the simulation, evaluation, and deep convergence of multiple patterns to analyze and improve service efficiency, reduce costs, and increase the competitiveness of crossover service providers. Service patterns are usually the most important parts of enterprise service implementation as well as key factors that determine the competitiveness of enterprises and the development of the MSI. To combine resources and services from different fields, achieve upstream and downstream integration, and clarify the value flow, the effective and comprehensive service pattern computation theory and methodology are necessary. Keywords Service pattern · Pattern model · Pattern simulation · Pattern evaluation · Pattern convergence

J. Chen (B) · M. Xi · J. Yin · S. Deng Zhejiang University, Hangzhou, China e-mail: [email protected] M. Xi e-mail: [email protected] J. Yin e-mail: [email protected] S. Deng e-mail: [email protected] © Zhejiang University Press 2023 J. Yin et al. (eds.), Convergence in Crossover Service, Advanced Topics in Science and Technology in China 68, https://doi.org/10.1007/978-981-19-8844-8_2

29

30

J. Chen et al.

Modeling and computing service patterns have become the focus of many enterprises in business innovation [1]. In recent years, artifact-centric BP-modeling methods and business model analysis frameworks based on business transaction processes have emerged globally to analyze and model service patterns. Zhejiang University proposed the concept of crossover services along with their 3C characteristics for the first time and explored the law of convergence. However, the academic community generally remains in the exploratory stage regarding the nature of service patterns, quantitative analysis of the model, evaluation methods, and convergence frameworks. Without a corresponding service pattern-oriented theoretical basis and practice method, in-depth understanding and analysis of crossover service patterns are lacking, leading to inefficiency and disorder in crossover service development. In this chapter, we aim to provide a panorama of the modeling and computation of crossover service patterns, including the pattern-description model, simulation system, evaluation metrics, and convergence method.

1 Crossover Service Pattern Modeling and computing crossover service patterns have become important means to promote the rapid development of the MSI. With the rapid development of Internet and cloud technologies, the pace of digital transformation within traditional industries has been greatly accelerated. The combined practices of business, processes, data, entities, and a range of other industry elements that occur during enterprise transformation and innovation can be broadly described as service pattern modeling and computation. Unfortunately, not all crossover service designs are successful. One reason for their failure is the current lack of in-depth understanding and analysis of the service pattern. Service patterns abstract BPs from four perspectives: workflows, data flows, resource flows, and value flows. Thus, computing service patterns are the essence of crossover services. The simulation, evaluation, and convergence of multiple models can improve service efficiency, reduce costs, and increase the competitiveness of crossover service providers. However, simple combinations of crossover service patterns can lead to many problems, such as low resource utilization and inefficient collaboration. In this section, we introduce the background, challenges, and technical framework of crossover service patterns.

1.1 Service Pattern For the emerging crossover services represented by e-commerce and Internet hospitals, the design of service patterns is particularly important [2]. However, due to the lack of theory, methodology, and framework for service patterns, the problems of systematically designing, effectively simulating, comprehensively evaluating and efficiently innovating service patterns have not been solved. The study of service patterns can greatly clarify the process of service ecological development and reduce confusion in the investment market.

Crossover Service Pattern: Modeling and Computing

31

Service patterns for crossover services typically have two characteristics. First, service patterns involve a large number of business strategies, many of which are not quantified and documented. Differences between business strategies are often ambiguous, and the general definition of business models cannot distinguish the subtle differences in the business policies of separate service patterns. Second, different policies of service patterns have different effects on services, and subtle changes in policies eventually affect the final profitability of BPs. Therefore, the expression of the service pattern must consider factors, such as the industrial chain environment and synergy effects, transfer elements, resource descriptions, and value models. As the ultimate purpose of the service pattern is to study the service’s value, the transformation of value is a process that needs to be quantified. A quantitative service pattern can distinguish the impact of different business strategies and selection strategies, and this impact can also be reflected precisely. The current business model innovation mainly relies on the analysis of existing ones by domain experts, which is highly subjective, random, and inefficient. This method cannot meet the requirements of large-scale complex business model construction. However, with the progression of time and environments, target groups, resources, and collaborators are changing, and no service pattern can maintain good profitability all the time. Therefore, service patterns need to be integrated with others and evolve with the times, as the market will uphold the appropriate service patterns and eliminate the inappropriate ones. The importance of service pattern convergence to crossover services has been unanimously recognized by both industry and academia to address its complex, dynamic and cross-domain characteristics. Most current research on service patterns stays at the level of qualitative analysis and lacks quantitative calculation methods [3]. Business Process Model and Notation (BPMN)1 and Business Process Engineering Language (BPEL),2 the most widely used traditional BP-modeling methods, mainly focus on service operation and process management. Joyce proposed a business model canvas that uses nine elements to analyze the business model [4]. Because production processes are the result of practice evolution rather than formal design in many complex services, Barros proposed a process architecture pattern for designing particular components of a complex service [5]. As most service pattern research in management remains qualitative, it is impossible to accurately determine the essential law of a service pattern from its details. Therefore, it has become a pressing issue to coordinate business services across multiple domains, model the interactions among participants, and quantify service patterns. Some have attempted to transform traditional industry processes into digital BPs to provide them with computational power. Li et al. considered the service pattern as a workflow-based exchange of resources and proposed a domain-specific language to help enterprise managers analyze basic business strategies [6]. Gao et al. explained different topic-evolution patterns and built a topic-evolution graph to reveal evolutionary trends [7]. 1 2

Business process model and notation (BPMN), https://www.omg.org/spec/BPMN/. Business process engineering language (BPEL), https://www.tutorialspoint.com/bpel/.

32

J. Chen et al.

1.2 Computational Framework So far, much work has been carried out on service patterns from different perspectives. Most existing approaches focus on describing business models and cannot systematically describe service patterns in an internet environment. Besides, service patterns cannot be simulated effectively. Current simulation systems, such as Anylogic,3 are excellent in the field of sociology. However, these systems require significant programming effort and professional support. Moreover, these systems are unable to model the service environment. For evaluation, the feasibility of the service pattern is mainly determined through rough market research and analysis, but without effective simulation tools, it is not possible to fully evaluate the service pattern. Modern modelevaluation methods, such as due diligence, can only determine whether a company has financial or legal problems. In Ref. [8], to study the profitability of service, the resource-usage situation has been fully extracted. In addition to resources, there are many aspects to assess service patterns, such as workflow. However, there is no comprehensive assessment method for the time, cost, efficiency, value, and reliability of the business. All of the above reasons lead to the inability to effectively converge the service pattern. New service patterns often face a large number of iterations during implementation, and merging existing service patterns with new service patterns is quite complex. It can be seen that the existing methods are mainly focused on the analysis, reflection, and repair of existing business models and lack advance simulation and prediction tools, rendering service pattern innovation simple, but risky and unpredictable. Some companies are trying to transform traditional industry processes into digital BPs to improve service design and analysis. However, existing business process-modeling approaches, such as BPMN and BPEL, primarily focus on workflows and are unable to provide a panoramic view of service patterns. A large amount of manpower and long-term testing are necessary for today’s service pattern convergence. Therefore, coordinating business services across multiple domains, simulating interactions among participants, and quantifying service patterns have become pressing issues [9]. In this chapter, we propose a set of service pattern-oriented computation systems and tools to support service pattern convergence [10]. These tools are intended to help startups design and simulate service patterns that provide forecasts and outlooks, as well as evaluate and innovate existing patterns to obtain viable solutions for the evolution and convergence of service patterns. As shown in the figure below, this set of solutions consists of the following four areas of functionality. As shown in the figure below, this set of solutions consists of the following four areas of functionality (Fig. 1). (1) Service Pattern Modeling and Design. A formal service pattern-description model and representation methods are used to accurately record and disseminate service patterns. The patterns formalized by this module can be used in the simulation and convergence process. 3

“Anylogic,” https://www.anylogic.com/.

Crossover Service Pattern: Modeling and Computing

33

Fig. 1 Technical framework of service pattern-oriented computation

(2) Service Pattern Simulation. An automated service pattern simulation method predicts occurrences in the actual operation quickly and efficiently. The simulation results provide a reference for convergence strategies and help evaluate the service patterns. (3) Service Pattern Evaluation. A quantitative service pattern evaluation method supports the comprehensive analysis of various service patterns and provides a scientific basis for decision making. The metrics are objectives used in convergence result selection. (4) Service Pattern Convergence. Intelligent service pattern convergence methods can systematically discover new available business forms and promote the rapid development of crossover services.

2 Crossover Service Pattern Model A crossover service pattern is a general description of the service-coordination mechanism, participant-interaction scenario, and data/resource/value-allocation method in a crossover business [11]. In the context of the convergence and innovation of the new generation of IT represented by cloud computing, IoT, mobile internet, and big data with the traditional service industry, various innovative service patterns, such as shared services, platform services, and online and offline services, have emerged. Compared with the rapid innovation and emergence of industries, the development of service pattern theories is lagging behind. There is a lack of in-depth

34

J. Chen et al.

research on the internal laws, quantitative analysis, and calculation of crossover service patterns. Therefore, the construction of a suitable model is of great significance for the systematic description, simulation, analysis, quantitative evaluation, integration, and innovation of service patterns. However, due to the interaction, mining, and integration of businesses, information and processes across multiple domains and industries coexist in crossover services. Thus, the crossover service pattern has obvious cross-domain behavior, integration, and complexity. The traditional service model only contains service providers, consumers, and objectives, and cannot easily cover important crossover service pattern components, such as service carriers, processes, resources, and values. Challenges, such as the systematic description and differentiation of service patterns with identical BPs as well as the quantitative and comprehensive assessment and comparison of service patterns, need to be overcome. In this section, we introduce a quantitative service pattern-description language: SPDL-Q. The elements in SPDL-Q are defined in a top-down manner, along with corresponding examples taken from the middleman e-commerce pattern.

2.1 Definition of Service Pattern Model The service pattern Γ abstracts the business relationship among products from the four perspectives of workflow, data flow, resource flow, and value flow according to definition 1. Participants form associations through workflows by declaring nodes of their actions. Data, resource, and value flows begin and end at nodes within the workflow. Thus, they can also represent the exchange of data, resources, and values among participants. A service pattern is a 6-tuple: Γ = (idΓ , D, Θ, V, P),

(1)

where idΓ is the identifier, D is the set of data flows, Θ is the set of resource flows, V is the set of value flows, w is the workflow, and P is the set of participants. A service pattern is illustrated using the example of a middleman e-commerce pattern in the Table 1. By definition, this service pattern consists of three data flows, two resource flows, and five value flows based on the workflows among four participants.

2.2 Perspectives of Service Patterns The key perspectives of service patterns are the workflow, data flow, resource flow, and value flow. A workflow represents a BP that can exchange data, resources, and values. There are three types of nodes in a workflow, namely, activities, gateways, and events,

Crossover Service Pattern: Modeling and Computing

35

Table 1 Service pattern example: a middleman e-commerce pattern © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307] P : Participants

Seller, customer, logistics company, financial institution

w : Workflow

Online transaction workflow

D : Data flows

Seller logistics data flow, consumer logistics data flow, Return logistics data flow

Θ : Resource flows

Transaction resource flow, return resource flow

V : Value flows

Advance payment value flow, seller settlement value flow, logistics settlement value flow, return logistics value flow, return refund value flow

Table 2 Workflow example: online transaction workflow © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307] A : Activities

Place an order, pay for the order, confirm payment, consign for shipment, …

G : Gateways

Whether to return, whether need to send back

E : Events

Start transaction, transaction success, transaction failed

F : Connectors

{Flow_0s2tw9v, start transaction, place an order}, {Flow_0jrv32v, place an order, pay for the order}, …

which are linked by a set of connectors (see Eq. 2). w = (idw , A, G, E, F),

(2)

where idw is the identifier, A is the set of activities, G is the set of gateways, E is the set of events, and F is the set of connectors. Table 2 describes an example online transaction workflow. Activities are used to represent actions performed by participants, such as placing an order. Gateways can route workflows to different branches depending on the situation and ultimately generate events for successful or failed transactions. All activities, gateways, and events are connected through a flow. A data flow describes the communication between participants and includes a name, type, size, and connector. A data flow is a 5-tuple defined as d = (idd , n d , κd , ∈d , f ) ∈ D,

(3)

where idd is the identifier, n d is the name, κd is the data type, ∈d is the size, and f is the connector to indicate the transference of the data. The data type can be any common or custom data format, such as JSON or XML. The connectors involved are used to describe the producers and consumers of the data. Table 3 illustrates the seller’s logistics data flow. The data flow carries 2048 bytes of seller logistics data in JSON format, which is generated during the “ship the goods” activity and used in the “agree the request” activity.

36

J. Chen et al.

Table 3 Data flow example: seller logistics data flow © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307]

n d : Data name

Table 4 Resource flow example: transaction resource flow © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307]

Seller logistics data

κd : Type

JSON

∈d : Size

2048 byte

f : Connector

{Flow_1cv14qy, ship the goods, agree the request}

n θ : Resource name

Goods

κθ : Type

Clothes

∈θ : Weight

1000 g

f : Connector

{Flow_0zgwtcp, consign for shipment, confirm receipt}

A resource flow describes a physical asset that is delivered according to the workflow for a transaction between two participants. A resource flow is a 5-tuple and is defined as θ = (idθ , n θ , κθ , ∈θ , ∈θ , f ) ∈ Θ,

(4)

where idθ is the identifier, n θ is the name of the carried resource, κθ is the type of resource, ∈θ is the weight, and f is the connector to indicate the transference of the resource. The type of resource includes products such as food and clothing. This will be ∈θ , the weight of the resource. Table 4 illustrates the transactional resource flow. The resource flow represents a 1000-g shipment of the clothing class sent in the “consign for shipment” activity and received in the “confirm receipt” activity. The value flow refers to the currency transactions among participants in the service pattern. The value flow includes the value name, currency used, volume, and connector. It is a 5-tuple defined as v = (idv , n v , κv , ∈v , f) ∈ V,

(5)

where idv is the identifier, n v is the name, κv is the currency type, ∈v is the volume, and f is the connector to indicate the transference of value. The connector in the value object indicates the node that provides and receives the value. The delivery of data, resources, and values occurs only if all nodes of the connector have completed their tasks. Table 5 describes an example value flow representing a 200-CNY payment for goods that is paid in the “pay for order” activity and confirmed in the “confirm order” activity. Connectors can be used to describe business logic, data transfer, resource transfer, and value exchange in workflows. The source and target nodes of the connector should be linked to related activities, gateways, and events. A flow connector is a triple and is defined as

Crossover Service Pattern: Modeling and Computing Table 5 Value flow example: advance payment value flow © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307]

37

n v : Value name Payment for goods κv : Type

CNY

∈v : Volume

200

f : Connector

{Flow_06nc2to, pay for order, confirm order}

f = (id f , ids , idt ),

(6)

where id f is the identifier, and ids and idt are identifiers of the source and target nodes, respectively. A source or target node could represent one of the activities, events, or gateways. As shown in Eq. 6, in addition to declaring the activities, gateways, and events that they need to perform, the participant also has a type property. Participant types κ p are primarily used to represent the organization or parent node of a participant and allow references to other participants. This enables relationships between participants to form a tree structure in order to identify the domains of participants in a complex service pattern. The type for participants that are not subordinate to another one should be the reserved word “personal.” A participant is a 5-tuple and is defined as p = (id p , κ p , IDa , IDg , IDe ) ∈ P,

(7)

where id p is the identifier; κ p is the type; and IDa , IDg , and IDe are the identifiers of the activities, gateways, and events in which the participant participates, respectively. κ p is mainly used to represent the organization or superior of the participants. Table 6 shows an example of a consumer participant. The consumer participates in five activities, one gateway, and one event. In this example, because both the consumer and seller types are “personal,” it is clear that the middleman e-commerce pattern shown also follows the C2C model. For workflow nodes, namely, events, activities, and gateways, we follow the commonly agreed convention. In short, these events mark the start, middle, and end states of the service pattern. Each activity represents an API, Web service, or functional component. Gateways are primarily responsible for routing and forwarding complex requests for Web services. To support the quantitative computation of service patterns, we extended the properties of events, activities, and gateways. Extended properties include carrier Table 6 Participant example: customer © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307] κ p : Type

Individual

IDa : Activities Place an order, pay for the order, confirm receipt, apply for return, consign for return IDg : Gateways Whether to return IDe : Events

Start transaction

38

J. Chen et al.

m ∈ M, time T , cost C, and reliability R. m represents the platform, server, or any environment on which the node is deployed. T and C indicate the duration and capital that the node may occupy in a single run. R is the probability that the node will run successfully.

2.3 Comparison and Discussion In this section, we compare SPDL-Q, SPDL, BPMN2.0, and artifact-centric BP model (BPM), as described in Table 7, to illustrate the key innovations and benefits of SPDL-Q. SPDL-Q is important for the following features. (1) A specific result of the pattern can be produced. BPMN2.0 and artifact-centric BPM can only describe the business from a process perspective, not the resource Table 7 Comparison between models © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307] Artifact-centric BPM

BPMN2.0

SPDL

SPDL-Q

Activity

Status between tasks

Atomic or choreographic tasks

Personalized service

Personalized service, extended carrier, time, cost, reliability

Gateway

Structured activities

Divergent or convergent controllers

Process controller

Process controllers, expansion carriers, time, cost, reliability

Sequence flow

The status sequence of the artifact

Logical relationships between nodes

Logical relationships between nodes

Node order relationships and contains intermediate time

Data flow

Entities, pairs of data names and attributes

Data input, output, and storage

Added data attributes and states

Quantifiable virtual sources, extended data types, and sizes

Resource flow

No

No

Available Quantifiable sources of wealth physical sources, expanded categories and weights

Value flows

No

No

As a special case Cash or virtual of resource flows currency, expanded currency and trading volume

Crossover Service Pattern: Modeling and Computing

39

and value flows in the pattern. Although the SPDL supplement describes the resource flow, it cannot provide a comprehensive description of the value flow. In addition, none of these three modeling methods support a quantitative description of service patterns, so they cannot provide a comprehensive analysis of the business. SPDL-Q adds attributes and elements, such as time, cost, reliability, data flow, resource flow, and value flow, to the traditional service process model. Service designers can fit the possible values of related properties with different conditional probability distributions and then measure the normal performance of service patterns based on their time, cost, efficiency, and reliability. In addition, a specific type of pattern result can be generated from these values. (2) Decisions in pattern design can be enabled. Artifact-centric BPM, BPMN2.0, and SPDL are primarily used to guide development. However, the lack of a quantitative description of the business elements makes it impossible to find bottlenecks and flaws in the pattern. Today’s service-pattern optimization is mainly directed by the project manager through brainstorming, which usually requires a substantial time and manpower investment, but its effectiveness cannot be guaranteed. While quantitative analysis methods, such as quality of service (QoS) are proposed, they are still insufficient to assess the resources and value flows of a business or draw conclusions at the design stage. SPDL-Q evaluation metrics include time, cost, efficiency, reliability, value creation, normalized spending, and pattern entropy. These indicators are typical, consistent, operational, and comprehensive. They reflect not only the main characteristics and states of the service pattern, but also its advantages and disadvantages. With the help of SPDL-Q, it becomes clear during the design of a new service pattern whether it meets the expectations of each level, where its bottlenecks are, and what its optimization direction should be. (3) The effects of pattern change can be predicted. Quantitative analysis methods based on traditional modeling methods, such as artifact-centric BPM or BPMN2.0, are designed for implementation after business deployment. For example, the necessary properties used in QoS analytics can only be obtained after the business is deployed. Furthermore, these methods cannot describe resources and value flows. While SPDL allows for a more comprehensive depiction of service patterns, it still faces the same problem. This results in insufficient analysis and slow iteration of service patterns. With SPDL-Q, the MSI can simulate service patterns using conditional probability distributions and historical data. Businesses can judge in advance whether new features will have a positive impact on the system. In addition, a comprehensive quantitative analysis of changes can be performed during the design phase of a new pattern.

40

J. Chen et al.

3 Crossover Service Pattern Simulation Simulation of the crossover service pattern is an effective method to estimate the operational performance of the pattern in advance by instantiating the participants, data, resources, value, and other elements and simulating their interactions [12]. It can assess the likelihood of realizing the expected value and help identify potential risks of implementing the pattern. Conventional estimation approaches for service patterns are based on the comparison of similar patterns and empirical judgments. For example, the Business Model Canvas proposes nine important factors for a company’s value creation activities, including customers, channels, revenue flows, etc. This approach to describe a service pattern helps highlight its core competitiveness. However, there are several problems with this approach. First, the model does not support the emerging cross-domain of businesses involving multiple industries and players, as it lacks the systematic knowledge representation to model multi-industry knowledge. Second, the model does not describe specific BPs to support quantitative analysis. Two patterns described by the Business Model Canvas can be compared to enable empirical study, and the outcome of a service pattern can be estimated based on the execution of similar known service patterns. However, crossover service patterns are often innovative, making it difficult to find similar cases for study. Within computer science, many flexible architectures have been proposed to quickly respond to changes in BPs at a minimal cost. It modularizes the subsystems shared between different parts of the BP as services. The services are integrated into a composite service pattern by pattern languages such as BPMN and SPDL, through which companies can reuse existing services and create a new composite service. A company’s service pattern reflects a company’s business model. It is executable and enables quantitative analysis. As described in the previous section, we have introduced the SPDL-Q, which extends SPDL with elements of business model theory to enable value analysis of a service pattern. Service patterns are represented based on the ontological model and SPDL-Qbased service pattern model. Ontology provides a dictionary that describes key elements of the business. The following subsections take the Fliggy insurance business as an example and describe the model method.

3.1 Simulation-Oriented Model Extension Crossover business involves complex and heterogeneous knowledge from different fields. We describe this knowledge using Web Ontology Language (OWL). It uses classification hierarchies and constraint features to classify elements and their relationships, and is easy for management experts to understand. It also has a strict set of rules that enable automated inference and validation. Therefore, it is well-suited to modeling services and domain knowledge of BPs. In addition, OWL has many

Crossover Service Pattern: Modeling and Computing

41

existing standard tools and modeling principles we can adapt or reuse. Existing OWL libraries can also be used to extend domain knowledge. As illustrated in Fig. 2, there are nine ontologies for service pattern simulation. The top-level ontology defines shared attributes across all ontologies, such as the name. Participants include all stakeholders involved—individuals or groups with interests or influences. In the Fliggy model, participants include Fliggy, Fliggy platform users, Ant Insurance, Alipay (an online payment platform), and service providers (hotels, airlines, etc.), as listed in Table 8. For simplicity, we select a hotel to represent all service providers. Tasks correspond to the task representation in SPDL-Q. The task structure is described by role, resource, condition, result, and time cost. Roles describe where participants can be during a task, resources are dependencies of tasks, and condition describes the conditions under which a task is performed. If the task conditions are not met but the task must be performed, an error message is thrown to the modeler; the result is a piece of code that will be executed while the task is executed. For example, the code to perform an online payment follows.

Fig. 2 Relationships among ontologies © [2022] IEEE. Reprinted, with permission, from Ref. [5301680921143]

Table 8 Agents in Fliggy model © [2022] IEEE. Reprinted, with permission, from Ref. [5301680921143] Participator

Value requirements

Resource

Online travel companies

Increase income; increase platform users; increase the order volume

Travel apps; money; bank account (account)

Platform users

Reduce risk; get travel services Money; accounts

Online payment companies

Increase revenue

Online payment platforms; money; accounts

Hotel

Increase income; increase occupancy rates

Room; money; accounts

Insurance company

Increase income; increase occupancy rates

Insurance platform; money; accounts

42

J. Chen et al.

money=payer.availableResource(‘money’) money=money.split(order_data.amount) money.setBelonger(‘payee’) For protracted tasks, as opposed to point-by-point tasks, transitional actions affect settings at the end of task execution. Time cost describes how many steps the task took when simulated. Through interaction of the characters, the task also describes the partnership and exchange of value between the participants. The Fliggy pattern process in SPDL-Q is illustrated in Fig. 3. In the process, platform users choose whether to travel. If they choose to travel, they select a hotel. Some platform users may purchase insurance. Before travel, some platform users may cancel the order. Users that have purchased insurance can claim compensation. Otherwise, the hotel provides a room. Finally, the platform charges a handling fee. The remaining amount is sent to the hotel and insurance company. By analyzing Fliggy’s user cases, we can identify the tasks in the pattern. Certain tasks, such as online payments, can be reused from the system’s schema libraries, which are predefined by management experts. Some tasks still need to be defined. The tasks involved are booking a hotel, purchasing insurance, cancelling an order, insurance indemnity, online payment, and hotel services. Resources are the media and dependencies of a task. A resource can be any physical, financial, human, or informational factor that supports a task in the service pattern. In particular, data objects are a special resource that can be copied and reused until they expire. Resources can be owned by participants and have attributes such as quantity, units, and whether they have locks. According to the task’s ontological definition, data objects include order and insurance data. In addition, money, hotel rooms, and bank accounts are involved. The observer model contains all the indicators in the system and the causal relationships among them. Participants can observe these indicators as parameters for task execution or the output of a simulation. In the Fliggy model, several metrics are

Fig. 3 Service process of Fliggy © [2022] IEEE. Reprinted, with permission, from Ref. [5301680921143]

Crossover Service Pattern: Modeling and Computing

43

Fig. 4 Causal relationship between indicators © [2022] IEEE. Reprinted, with permission, from Ref. [5301680921143] +

defined to assess the realization of value requirements, as shown in Fig. 4, where − → − (− →) indicates that two metrics have a positive (negative) correlation. For example, platform user satisfaction and average satisfaction are introduced to represent the sum of these two goals. User satisfaction ranges from 1 to 100. In many cases, a platform changes their satisfaction rating. For example, if no hotels have any rooms available, the satisfaction of users who want to book a room is reduced by twenty. Otherwise, it will increase by ten. We assume that the platform’s user growth and hotel growth follow an S-shaped b curve. The growth equation (gr ) is

gr = r ∗

K−N , N

(8)

where K is the maximum environmental capacity and N is the current number. r is a factor positively correlated with the average satisfaction of platform users; for hotels, this factor is positively correlated with their average profit margin. The Expertise Ontology contains elements that modelers can extend for domain applications. For example, if the service pattern involves spatial relationships, a hierarchy of locations can be included. In Fliggy’s case, the price of a hotel room is stored as a subclass of the hotel service. The environment ontology describes external activities that affect the model, such as introducing new participants into the model. In our example, we define the addition of platform users and hotels at each step of the simulation. These two global operations are achieved by writing code in the properties of both environment concepts. Service patterns describe BPs in the model using SPDL-Q, which enables additional attributes and elements to be attached to standard SPDL-Q elements. As shown in Fig. 3, in the original form of SPDL-Q, a single participant typically performs a task. However, modeling the entire process is too granular, as it contains many details that are not related to value creation. Therefore, instead of applying swim lanes in the diagram, we use figures of people to represent the characters of the multirole task. It shows how participants collaborate with others while performing tasks. Modelers can drag tasks and other SPDL-Q elements from the color palette on the left. Tasks in the palette are defined in the ontology. Then, a role is assigned to the

44

J. Chen et al.

defined participant concept for each task. Only instances that belong to this participant concept are entitled to the role. The properties of other SPDL-Q components also need to be populated, such as conditional statements for exclusive gateways. In our example, depicted in Fig. 3, the main process is as follows. First, the platform user chooses whether to leave. The probability of leaving is equal to the user’s churn rate, as shown in Fig. 4, and the user can then travel according to the buyback rate. Next, the user chooses a hotel. If no hotel has rooms, the order fails. After selection, the platform user has a 50% probability of purchasing insurance; the insurance rate is 1% of the order. After payment, the money is held by Fliggy, which sends the order and insurance information to platform users. The platform users is assumed to have a 10% chance of cancelling the order, in which case, the user can claim compensation if insurance was purchased. Otherwise, if the user checks in, the hotel provides a room. Finally, the platform charges a 0.5% handling fee for the accommodation and insurance. The remaining amount is sent to the hotel and insurance company.

3.2 Process Simulation After the ontology and process are defined as shown in Fig. 5, some configuration is required before the simulation can begin. The first step is instantiation. The grouping mechanism is tunable, so multiple concepts can be instantiated at once. For example, the modeler can choose the concept, platform users, and funds associated with the owner as a group. The numeric property is then set to 1000 to create 1000 participants, each with money. This is convenient when a large number of instances are needed, which is normal in simulations. However, the original ontology editor can define individuals on a case-by-case basis. In Fliggy’s case, the model instantiates 500 platform users, 300 hotels, Fliggy (an online travel company), Alipay (an online payment company), and Ant Insurance (an insurance company), along with their value needs, resources, and metrics. The maximum capacity of platform users and hotels is 20,000 and 800, respectively. Second, the instantiated participant should be bound to the role in the service pattern. This indicates who will perform the task within the process. Finally, processes and configurations, such as the maximum step size, are loaded by the BPMN engine. Because the existing engine does not support ontological reasoning and extended BPMN notation, we write our own. Each instance is bound to an ontological object in the system. Once instantiated, an object can access its ontology specification using SPARQL, the semantic query language of the Resource Description Framework that allows an ontology object to be inserted, deleted, updated, or queried on itself, its properties (data properties), or its relationships (object properties). After loading, the BPMN engine starts. In each step, multiple processes are executed according to the settings of the startup event, which provides scheduled events, trigger events, and interval events. Participants in the startup event decide whether to start the BP and assign participants to each role. In the Fliggy example,

Crossover Service Pattern: Modeling and Computing X 1000

TopLevel Ontology

Participant Ontology

Resource Ontology

45

instantiate

Task Ontology

Platform Own user

Money

Bind b) Instances Definition

maximum step: 100 has insurance: True init satisfaction: 50

······

load

d) Simulation Config

Platform

user Plat f orm user

Money

Online payment

······

a) Ontology Definition

refer Online payment

······

Other Task

c) Process Definition

load BPMN Engine e) Simulation

Fig. 5 The process of simulation. a Modelers define concepts involved. b Instances of concepts are defined. c The service pattern is described by BPMN. Instances defined are bound to the process. d Configurations of the simulation are filled. e The configurations and service pattern defined are loaded into the BPMN engine. At last, the simulation can start. © [2022] IEEE. Reprinted, with permission, from Ref. [5301680921143]

interval events are applied. At every step, each platform user considers whether to travel or leave. In addition, owing to its ontological basis, the OWL-S inference function is applied to allow dynamic matching and context-sensitive computation of task results at runtime via SPARQL. For example, in a transport task, the task only states that vehicles are required. At runtime, the type of vehicle can change within the same task depending on the role. Currently, there are two types of environmental modeling methods. One approach is to represent environmental factors as agents; the other is to extend BPMN with new environmental elements. In our system, we apply the first method. An instance of the environment ontology performs actions at each step and can change the state of other instances globally. In our opinion, this helps modelers separate environments and service patterns, allowing them to easily experiment with different combinations of environments and service patterns in addition to using the token in the engine to transfer process data. As a result, participants can share information with others.

3.3 Case Study After modeling Fliggy’s business, we used our system to simulate 110 steps and analyzed the results. An analytical view of the system is shown in Fig. 6. We compare two service patterns: the old pattern, which does not introduce cancellation insurance (represented by the light orange line), and the new pattern, which does (represented by the orange line). New and old patterns grow and eventually stabilize because the number of platform users reaches the maximum market capacity, or their churn rate is equal to the growth rate. As can be seen in Fig. 6B, C, D, the new pattern significantly improves the advantages of the platform compared to the old

46

J. Chen et al.

Fig. 6 The result of simulation © [2022] IEEE. Reprinted, with permission, from Ref. [5301680921143]

pattern. Because cancellation insurance can help users reduce losses, their average satisfaction increases more quickly (Fig. 6A), their number is large (Fig. 6C), and increases (Fig. 6D). In Fig. 6, the occupancy curve has also become more stable due to the risk mitigation provided by insurance. However, in Fig. 6A, it is interesting that across the 45 steps (Fig. 6G1), the average satisfaction of platform users declines and stabilizes to a low value. Therefore, the number of users cannot reach its maximum capacity. As shown in Fig. 6G2, exploration of each step reveals that this is because the successful occupancy rate decreases at the same time. Furthermore, the underlying reason is that the hotel has reached its maximum market capacity and has not kept up with the needs of platform users, as shown in Fig. 6G3. In practice, if Fliggy attracts more hotels through discounts and other means, the bottleneck can be solved. In summary, the simulation shows that introducing cancellation insurance would help Fliggy attract more users and earn more income. Therefore, it should be implemented to help promote growth. However, while insurance can help users avoid risks, it can have a negative impact on their accommodation goals. This phenomenon reflects a conflict between the profitability of the platform and the goal of improving the user experience on the platform. This example shows how simulations can help decision makers identify problems in advance. Finally, we presented the case study to an Alibaba manager related to Fliggy. They fully affirmed the case and said they would consider our proposal.

Crossover Service Pattern: Modeling and Computing

47

4 Crossover Service Pattern Evaluation Crossover service patterns can be evaluated to comprehensively measure the performance of the enterprises’ patterns in terms of time, cost, reliability, efficiency, and value creation. The purpose of pattern evaluation is to provide a reference for the design and selection of crossover service patterns. At present, the assessment of service patterns is primarily based on qualitative evaluation and lacks quantitative calculation methods. The different types, diverse patterns, and complex processes of crossover services pose challenges for quantitative evaluation. Combining the value, process, objectives, and other important elements of crossover service patterns; objectively selecting and determining the metrics of crossover service patterns; and establishing a reasonable evaluation system have become important challenges for the development of the MSI. Unlike the traditional single-user, single-platform pattern, crossover services are deployed on different servers and executed by participants from different fields and organizations. Therefore, crossover service patterns are evaluated not only in terms of the performance at service execution, but also in terms of the collaboration impact introduced by multiparticipant cooperation and the transmission loss introduced by multiplatform interaction. For example, if there is a handover of activities among participants in a crossover service-pattern workflow, additional time is consumed by that collaboration process. In this chapter, we introduce service pattern evaluation metrics, including time, cost, reliability, efficiency, value creation, normalized expenditure, and pattern entropy, which take into account the collaboration of participants and services from multiple domains [13]. These metrics are intended to provide a comprehensive assessment and estimate of the service pattern against SPDL-Q during the design phase. Therefore, it is necessary to calculate the expected value of each metric based on the workflow in the service pattern. In practice, we use the pattern-simulation system to simulate a single execution of the pattern and estimate the indicator. When performing simulations and calculating these indicators, there are four main structures to consider: sequence, parallel, switching, and looping. The formulas to calculate indicators in each structure, which explain the logic of the operation when different structures are encountered, are described below.

4.1 Evaluation Metrics of Service Pattern The evaluation metrics of service pattern evaluation include time, cost, reliability, efficiency, value creation, normalized expenditure, and pattern entropy. Unlike the traditional single-user, single-platform model, different Web services are deployed on different servers and executed by different actors in one MSI business. Therefore, the service pattern time includes not only the web service execution

48

J. Chen et al.

time but also the cooperation time introduced by multiparticipant cooperation and the interaction time introduced by multiplatform interaction. On the one hand, if the source and target participants for the connector in the workflow fare differently, additional time is consumed during the collaboration process of the activity switchover. For example, in the middleman e-commerce pattern, because of the transit time required for express pickup, there are usually several hours between the seller’s consignment of goods and the logistics company’s delivery of goods, even though they are continuous activities. On the other hand, if the carriers of the source and destination are different, more information-transfer time is introduced. For example, in an Amazon Web Services environment, the call latency is approximately 25 ms, which is lower than normal cross-cloud connectivity. As shown in Eq. 9, T represents the total time of the service pattern. In a sequence structure, T is the sum of all N node times and all F connector times. Ti and T j are the times of the ith process node and jth connector, respectively. Ri is the reliability of the ith process node. In parallel structures, T is the maximum time of all K substructures, where Tk is the kth branch time. In a switch structure, T is the weighted sum of all K substructure times, where the αk is the probability of executing the kth branch. The time of the loop structure can be obtained by finding the limit, where αl is the entry probability of the loop and Tl is the duration of a single cycle. ⎧ ∑N ∑F ⎪ i=1 Ti /Ri + j=1 T j , sequence ⎪ ⎪ ⎨ max Tk , parallel T = 1≤k≤K ∑K ⎪ ⎪ α T , switch ⎪ ⎩ k=1 k k xloop αl Tl /(1 − αl ),

(9)

Because Web services in the MSI are usually deployed and operated separately, the schema cost should include the activity and gateway waiting costs in addition to the basic cost of service operation. For example, during an e-commerce transaction, even if the consumer does not return the goods, the return service still runs on the server, consuming energy and incurring costs. The cost is calculated by Eq. 10, where C indicates the total cost of the service pattern. In a sequential and parallel architectures, this cost is the sum of the base and wait costs for all nodes in the service pattern N . Cib is the basic operating cost of the ith node. Ciw is the waiting cost per unit time and Ti w is the wait time of the ith node. In a conversion structure, the cost is the weighted sum of the costs of all K substructures, where αk is the operation probability of the kth branch and Ck is the corresponding branch cost. The cost of the loop structure can also be obtained by finding the limit, where αl is the entry probability of the loop and Cl is the cost of a single cycle. ⎧ ∑N ⎨ ∑i=1 (Cib + Ciw Ti w ), sequence/parallel K C= α C , switch ⎩ k=1 k k loop αl Cl /(1 − αl ),

(10)

Crossover Service Pattern: Modeling and Computing

49

Reliability is the rate at which a service runs successfully and measures the probability that activity in a service process will run as required. Reliability affects the time and cost of a pattern. For example, if the reliability of an activity is 0.5, its uptime is doubled, and the waiting costs of subsequent nodes is also affected. The reliability is calculated using Eq. 11. In a sequential structure, reliability is the product of the reliability of all N nodes in a sequence, where Ri is the reliability of the ith node. In a parallel structure, reliability is the minimum of all K parallel substructures, where Rk is the reliability of the Kth branch. In a switching structure, reliability is the weighted sum of the reliability of all K substructures. The loop structure is also a special case of the switching structure and can be obtained by finding the limit, where Rl is the reliability of a single loop. ⎧ ΠN sequence ⎪ i=1 Ri , ⎪ ⎪ ⎨ min Rk , parallel R = 1≤k≤K ∑K ⎪ α R , switch ⎪ ⎪ ⎩ k=1 k k αl Rl /(1 − αl ), loop

(11)

The efficiency of the service pattern depends on the efficiency of the transfer of data, resources, and value. The calculation method is shown in Eq. 12. ∈o is the size/weight/volume of the data/resource/value objects in flow o. To is the corresponding transmission time of the flow. f O is a base function that normalizes the efficiency of the three types according to their units, and |O| is the number of elements in set O. E=

∑

( ) ∑ 1 ∈o fO 3|O| To

(12)

O∈{D,Θ,V} o∈O

Value creation refers to the added value generated by the exchange of value and resources in the service pattern. Added value arises from the fact that the same resource has different values for different actors. For example, a broken vase may be worthless to the seller, but may be a priceless antique to the customer. The vase transaction then creates additional value for both the seller and the customer. In short, the sum of the added value generated by each participant by exchanging resources and value in the service pattern constitutes the value creation of the model. For a participant, value creation is the difference between the sum of the value and resources they expect to acquire and spend in the pattern (see Eqs. 13 and 14). V p is the value creation of participant p. Vt , Θ t , Vs , and Θ s denote the value obtained, resources obtained, value spent, and resources spent, respectively. αv, p and αθ, p are the occurrence probabilities of value and resource transfer, respectively. Ψθ, p is the value-conversion rate of resource θ to participant p. The value creation of the pattern is the sum of the value creation of all participants within it (see Eq. 15). V=

∑ p∈P

Vp

(13)

50

J. Chen et al.

V p = SU M V ( p, Vt , Θ t ) − SU M V ( p, Vs , Θ s ) SU M V ( p, V, Θ) =

∑

αv, p ∈v +

∑

αθ, p Ψθ, p ∈θ

(14) (15)

θ ∈Θ

v∈V

4.2 Pattern Entropy and Normalized Expenditure To enable a holistic and comprehensive assessment of service patterns, two composite indicators, pattern entropy and normalized expenditure, have been proposed. Pattern entropy indicates the degree of chaos in a service pattern. For example, Eq. 16 shows that pattern entropy is the sum of the node, connector, data, resource, and value entropy. H=−

|M| ∑

Pi log|M| Pi −

i=1

∑

−

∑

|J| ∑

P j log|J| P j

j=1

Po log|O| Po ,

O∈{D,Θ,V} o∈O

s.t.Pi = |M| ∑ i=1

Pi =

Nj Ni ∈o , Pj = , Po = ∑ , |A ∪ G ∪ E| |F| o∈O ∈o |J| ∑ j=1

Pj =

∑

Po = 1

(16)

o∈O

∑|M| In Eq. 16, − i=1 Pi log|M| Pi is the value of the node entropy, where Pi represents the distributed probability of a workflow node running on the ith carrier. Ni is the number of workflow nodes running on the ith carrier, |A ∪ G ∪ E| is the total number of nodes, and |M| is the number of carriers involved in the service pattern. When most nodes run on a small number of carriers, the node entropy is small, which indicates that most services in the pattern run on a unified platform. For example, in Fig. 9, there are 3 types of carriers, a total of 18 nodes, and each type of carrier has 11, 5, 5 2 11 5 2 log3 18 − 18 log3 18 − 18 log3 18 ≈ 0.82. In or 2 nodes. Thus, the node entropy is − 11 18 Fig. 10, all 18 nodes run the same carrier, so the node entropy is 0 because log2 1 = 0 (when there is only 1 carrier, the cardinality of the log is 2). Obviously, a service pattern with more centrally deployed nodes results in smaller node entropy. Here, we define the connectors that connect nodes from the same type of partic∑|J| ipants as belonging to the same type. Similarly, − j=1 P j log|J| P j represents the value of the connector entropy, where N j is the number of flows of the jth type, |F| is the total number of flows, and P j indicates the probability distribution of the jth connector type. For example, in Fig. 10, there are 18 connectors of 12 types. In

Crossover Service Pattern: Modeling and Computing

51

Fig. 11 connectors are of 4 types, but the total number is also 18. As a result, the connector entropy of Fig. 11 (≈0.92) is less than that of Fig. 10 (≈0.95). Because the sellers, financial institutions, and logistics companies in the figure belong to the same type (all operated by e-commerce platform), it is clear that if participants in the service pattern need to collaborate more and with more variation, connector entropy increases. Data, resource, and value entropy are calculated by ∑ ∑ − O∈{D,Θ,V} o∈O Po log|O| Po in Eq. 16, where ∈o is the size of the object in data/resource/value flow o and Po indicates the probability distribution of the size in the flow. For example, suppose there are two data flows of the same size in a service pattern with a data entropy value of − 21 log2 21 ∗ 2 = 1. If we merge two data objects and implement them through one data flow, the corresponding schema entropy is reduced to 0. In other words, to reduce the value of these three terms, the service pattern needs to be designed to deliver larger objects in less time. To better understand these metrics, we plotted the Shannon entropy function in Fig. 7 with three variables, which is obviously a convex function. When the probabilities of all three variables are the same, the extrema are displayed. In other words, the smaller the value of H, the more orderly the service patterns. In summary, pattern entropy depicts the degree of chaos of a service pattern from five aspects. By pegging the bottom of the logarithm to the corresponding amount of change, the range of pattern entropy is limited to [0, 5]. As a result, service patterns can be compared with different numbers of activities, connectors, data flows, resource flows, and value flows under unified metrics. To fully assess and compare service patterns through unified indicators, we propose normalized expenditure, which represents the loss of revenue per unit

Fig. 7 Illustration of entropy function with 3 variables © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307]

52

J. Chen et al.

for each successful run of each node in the pattern. This loss is the logarithmic sum of the time and cost consumed by the pattern and represents the product of data/resource/value transfer and value creation. In Eq. 17, N is the total number of process nodes. From the proportional relationship between the expenditure and each of the indicators involved, the model expenditure is found to decrease with decreasing time and cost of the model and increasing reliability, value creation, and efficiency, i.e., L ∝ {T , C, 1/R, 1/V, 1/E}. Normalized expenditure can be used to optimize service patterns by converting an optimization problem from multiobjective to single-objective. L=

log(T + 1) + log(C + 1) N ∗R∗V∗E

(17)

4.3 Data-Driven Case Study From the perspective of market regulators, this section applies four typical patterns of e-commerce, namely, the middleman, platform, proprietary, and new retail patterns, to SPDL-Q. Figure 8 depicts the mapping among the graphic and SPDL-Q elements. Each graph represents a service pattern, and each lane represents a participant who performs or participates in the activities, gateways, and events within it. The participant’s name is displayed on the left side with a color block to show its type, which is primarily used to represent a participant’s organization or superior and allows references to other participants. Activities, gateways, and events are represented by squares, diamonds, and circles, respectively, and are connected by solid lines. The color block in the upper left corner represents the carrier of the node, that is, the server on which the activity, gateway, or event is running. In fact, the operator shares the same fields as the participant type. Dataflows, value flows, and resource flows are represented by dot-dashed, dotted, and dashed lines, respectively. A graphical representation of the four patterns based on SPDL-Q is shown in Figs. 9, 10, 11 and 12, which can be considered the patterns experienced at different stages of e-commerce development. It is not difficult to see that these patterns share the same or similar workflows to those in the diagram above. However, the difference

Fig. 8 Symbols for SPDL-Q diagrams © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307]

Crossover Service Pattern: Modeling and Computing

53

Fig. 9 Middleman pattern © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307]

Fig. 10 Platform pattern © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307]

between the patterns highlighted with the red circle can still be clearly indicated by SPDL-Q. Through the evaluation indicators proposed in this chapter, we can quantitatively evaluate and compare the four patterns. Here, we assume that approximately 1 kg of goods worth 200 CNY are traded in four patterns. We set the properties of the pattern elements in the graph as uniform (U), Poisson (P), and exponential (E) distributions (see Table 9). For each pattern, we perform 1000 iterations of simulation and then calculate the mean and variance of the evaluation metric. The results of the assessment are shown in Fig. 13. The middleman pattern is an e-commerce pattern in which an e-commerce company is only responsible for building an online platform to broker transactions without providing other additional services, such as financial and logistics services (see Fig. 9). In the middleman pattern, there are four participants. Consumers and sellers are different individuals, and the activities they use are provided by ecommerce companies. Financial institutions and logistics companies offer their own services to help consumers and sellers complete transactions together.

54

J. Chen et al.

Fig. 11 Proprietary Pattern © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307]

Fig. 12 New retail pattern © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307]

Under the middleman pattern, e-commerce companies are only responsible for building online shopping platforms to match consumers and sellers. The completion of the exchange of value and resources requires the support of TP logistics companies and financial institutions. As a result, users’ data, resources, and value need to be exchanged between different platforms and applications. Thus, although the delivery time is expected to be 3 days, it takes an average of about 4.923 days to complete the transaction in this pattern. Meanwhile, manpower, logistics and operating costs are expected to reach 42.78 CNY per transaction. Unlike the middleman pattern, all services in the platform pattern are deployed on a unified platform for e-commerce, although there are still TP financial institutions and logistics companies involved in this pattern (see Fig. 10). For example, Taobao, a well-known e-commerce company owned by Alibaba, docks with TP logistics companies through Cainiao and with traditional banks through Alipay. All services, including Cainiao, Alipay, and Taobao, run on Alibaba Cloud servers. This

Crossover Service Pattern: Modeling and Computing

55

Table 9 Assessment parameters of four typical E-commerce patterns © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307] Parameter

Middleman pattern

Platform pattern

Proprietary pattern

New retail pattern

Campaign time (finance)

U(0.5, 1)/s

U(0.5, 1)/s

U(0.5, 1)/s

U(0.5, 1)/s

Event time (logistics)

P(3)/day

P(3)/day

U(1, 3)/day

U(10, 30)/min

Event time (seller)

P(60)/s

P(60)/s

P(60)/s

P(60)/s

Campaign hours (clients)

P(120)/s

P(120)/s

P(120)/s

P(60)/s

Gateway time

U(0.5, 1)/s

U(0.5, 1)/s

U(0.5, 1)/s

U(0.5, 1)/s

Flow time (basic)

P(50)/ms

P(50)/ms

P(50)/ms

P(50)/ms

Flow time (crossover)

E(0.5)/s

E(0.5)/s

E(0.5)/s

E(0.5)/s

Flow time (cooperation)

E(0.01)/s

E(0.01)/s

E(0.01)/s

E(0.01)/s

Active operating costs (finance)

U(0.5, 1)/CNY

U(0.5, 1)/CNY

U(0.5, 1)/CNY

U(0.5, 1)/CNY

Event operating costs (logistics)

P(6)/CNY

P(6)/CNY

P(8)/CNY

U(4,10)/CNY

Operating costs of the event (seller)

U(0.5, 1)/CNY

U(0.5, 1)/CNY

U(0.5, 1)/CNY

U(0.5, 1)/CNY

Active operating costs (customer)

U(0.5, 1)/CNY

U(0.5, 1)/CNY

U(0.5, 1)/CNY

U(0.5, 1)/CNY

Gateway operating U(0.5, 1)/CNY costs

U(0.5, 1)/CNY

U(0.5, 1)/CNY

U(0.5, 1)/CNY

Activity/gateway wait costs

U(0.5, 2)/CNY per day

U(0.5, 2)/CNY per day

U(0.5, 2)/CNY per day

U(0.5, 2)/CNY per day

Value

P(200)/CNY for goods, P(180)/CNY for seller, P(20) for logistics

Resource

P(1000)/g

P(1000)/g

P(1000)/g

P(1000)/g

Data

P(2048)/byte

P(2048)/byte

P(2048)/byte

P(2048)/byte

Reliability

U(0.995, 0.999)

U(0.995, 0.999)

U(0.995, 0.999)

U(0.995, 0.999)

unified deployment can reduce the time and cost of data/resource/value transfer among platforms to some extent. In terms of parameters, the platform pattern is consistent with the middleman pattern (see Table 9). However, because of the unified management of the service, the user’s data does not need to be transferred between servers on multiple platforms or even multiple regions. As a result, the additional time associated with service interactions can be greatly reduced. This allows the platform pattern to reduce the average time by 0.175 days (4.2 h) compared to the middleman pattern. The cost of this pattern is also reduced by approximately 2.248 CNY per transaction. The

56

J. Chen et al.

(a) Time

(b) Cost

(c) Reliability

(d) Data Efficiency

(e) Resource Efficiency

(f) Value Efficiency

(g) Value Creation

(h) Normalized Expenditure

(i) Pattern Entropy

Fig. 13 Assessment results of four typical e-commerce patterns © [2022] IEEE. Reprinted, with permission, from Ref. [5318280463307]

efficiency of the data, resource, and value transfer also increases (see Fig. 13). Finally, the pattern’s average normalized expenditure falls by about 6.67%. The unification of the carriers also decreases the mean pattern entropy from 4.578 in the middleman pattern to 3.758. In the proprietary pattern, e-commerce businesses provide a platform to sell their own goods through their own financial and logistics systems (see Fig. 11). This means that e-commerce companies can further improve the efficiency of supply chain collaboration by playing the roles of seller, financial institution, and logistics company simultaneously through different departments. For example, JD.com, one of China’s largest e-commerce platforms, sells goods from its own stores, receives payments through its own financial services (JD wallets), transships goods through its own logistics, and implements a typical proprietary pattern. In terms of parameters (see Table 9), owing to the unified control of the source of goods, the seller can deliver goods from the nearest source to the consumer, thus achieving a logistics time of 3 days. However, because this pattern requires largescale warehouse inventory and management, the logistics cost per delivery increases by 25%. From the evaluation results shown in Fig. 13, it is clear that the proprietary pattern greatly reduced the time to complete transactions, reaching an average of 2.519 days.

Crossover Service Pattern: Modeling and Computing

57

The transfer efficiency of data and resources was also increased by a factor of more than 1.5. The efficiency of value transfer also improved slightly, not only because of the reduced logistics time but also because of the efficiency of the supply chain collaboration. In addition, although the logistics costs increased by 25%, the overall cost of the proprietary pattern still fell from 40.53 CNY to 31.05 CNY for the platform pattern. Finally, through the integration of sellers, logistics, and finance, the normalized spending and pattern entropy of the proprietary pattern decreased by approximately 5.9 and 0.704%, respectively, compared with the platform pattern. The new retail pattern is based on a proprietary pattern to help consumers complete intracity transactions in a short period of time (see Fig. 12). It relies on the synchronization of goods deliveries and payments through online and offline collaboration. For example, FreshHema, Alibaba’s new retail business, sells daily necessities and fresh food. FreshHema’s offline store is deployed on a block-by-block basis, where each store is only responsible for orders from nearby streets. If the user places an order online, FreshHema transfers the goods from the nearest store. Owing to the characteristics of intracity transactions, the logistics process under the new retail pattern is usually completed within 30 min. However, because of the frequent small-batch distributions, logistics costs have not been significantly reduced. Logistics costs also increase at night and in bad weather. Therefore, the shipping cost of new retail orders is usually 4–10 CNY (see Table 9). As a result, the new retail pattern significantly reduced the total time expected per order from 2.5 days in the proprietary pattern to 0.03 days (43 min). The cost of a single transaction also fell from 31.05 CNY to 13.05 yuan, which is approximately 137.98% lower than the proprietary pattern. Because the logistics time is greatly shortened, the transfer efficiency of data, resources, and value is also greatly improved. Finally, the normalized expenditure of the new retail pattern reached 0.0078 for e-commerce, which is a huge improvement from the 0.2541 of the proprietary pattern. Due to the refinement of the pattern parallelism mechanism, the pattern entropy also decreases slightly.

5 Crossover Service Pattern Convergence The convergence of the Internet and traditional industries has given rise to crossover services. In the MSI, crossover and convergence is an important strategy for business expansion. Amazon launched a healthcare service, while Alibaba ventured into travel, medical services, restaurants, etc. We have found that many companies are playing the business game of integrating resources across corporate boundaries. Unfortunately, not all of the crossover convergence are successful. One reason for failure is the lack of deep convergence of service patterns, which is the essence of crossover services. Deeper convergence of multiple patterns can improve service efficiency, reduce costs, and make crossover service providers more competitive, whereas simple combinations can lead to many problems, such as low resource utilization and inefficient collaboration.

58

J. Chen et al.

Take Fliggy, for example, which was formerly known as Alitrip, an online travel agency offering airline tickets, hotel booking services, tour guide services, visa application services, and holiday packages. To meet the diverse needs of consumers, it has partnered with insurance companies to offer consumers access to purchase travel insurance. Consumers can choose whether to purchase the appropriate travel insurance at the time of booking. The convergence of the online travel agency (OTA) and insurance services reduces the risk from travel for consumers. However, there are some problems that plague consumers during operation, such as cumbersome procedures and low compensation efficiency. This indicates that the current interface between the OTA and insurance services is not satisfactory. Toward the convergence of crossover services, we analyze the general relationships that exist in service patterns and propose a rule-based framework to fuse crossover service patterns [14]. In this chapter, general rules for service pattern fusion are summarized from three perspectives: participants, resources, and service processes. Furthermore, a rule-based service pattern-convergence framework is proposed, which can help service providers design new crossover services. Moreover, the concept of rule-based service pattern convergence preserves important service logic in the process of implementing semiautomatic service convergence.

5.1 Rule-Based Service Pattern-Convergence Framework Based on the service pattern model of participants, service objectives, service values, service processes, resources, and relationships proposed in relevant works, the general relationships in the model are summarized, and a rules-based service patternconvergence framework is proposed (see Fig. 14). In this framework, a service pattern is represented by a graph. In this service pattern graph, diagrams depict participants, resources, processes, service values, service goals, and the relationships among them. Service pattern graphs facilitate the management of relationships among components. They are more flexible than existing descriptive methods, such as BPM, and can contain more service pattern information. In addition, they enable components to be reused in pattern fusion. Service pattern graphs are essentially heterogeneous

Fig. 14 Framework of service pattern convergence methods © [2022] IEEE. Reprinted, with permission, from Ref. [5304030122479]

Crossover Service Pattern: Modeling and Computing

59

information networks (HINs). Therefore, service pattern convergence is the fusion of two HINs. A rule-based service pattern-convergence framework is proposed that is composed of three parts: participant convergence, resource convergence, and service process convergence. Combined with previous work, the key components of the service pattern include the participant, service process, goal, value, and resource. We summarize the relationships as follows: • • • • • • •

Cooperate_with: Exists between two service providers; Support: The task requires resource support; Coordinate: Exists between resources; Own: Exists between participants and resources; Generation: Generate service value while a specific service process is completed; Has: Exists between participants and service objectives; Transfer_to: After generation, the value of the service will be transferred to the participants; • Next: Exists between tasks, revealing the order in which tasks are executed. In different patterns, there are different instances of participants. For example, consumers have different names between the online insurance and OTA patterns. For crossover services that contain multiple service patterns, participants in one pattern typically participate in another pattern as well. Therefore, identifying potential mapping relationships among participants in different patterns is key to participant convergence. Participant mapping rules are defined as i f P 1i → P 2k : P 1i ⇐⇒ P 2k ,

(18)

where P1i is the participant in the first service pattern and participant P2k in the other. This rule indicates that if there is a mapping relationship between two participants in different patterns, they can be merged into a new participant with all the resources and targets of the original pattern. There are two main types of resource fusion: resources for the same participant and resources for different participants. For the former, the key is to determine whether the resources are of the same type and whether they can accumulate in quantity. i f (mi nT y pe(R i j ) == mi nT y pe(R i k ) and , si m(R i j , R i k ) > θ ) : R i j = R i j + R i k

(19)

where is minT ype() the smallest classification unit and sim(Ri j , Rik ) is computed based on word2vec, a word embedding method. This rule means that if two resource instances have the same minimum classification unit, further similarity calculations are used to infer whether there is a common value between the two instances. If the colloquial is present, the attribute value is added to Rik Ri j .

60

J. Chen et al.

For the latter type of fusion, the key is to determine whether the resources between the different participants are related after convergence. For example, before convergence, the Fliggy and Ant Insurance platforms were not connected. After fusion, there is an exchange of information between them. In this case, we use a neighbor-based approach to measure the intimacy of two resource nodes. The higher the intimacy score, the higher the likelihood that there will be an edge between two nodes in the new pattern. The score is calculated as Scor e(r1 , r2 ) = |N (r1 )| × |N (r2 )| ,

(20)

where r1 and r2 are two resource nodes without edges. N (r1 ) and N (r2 ) represent neighbors of r1 and r2 , respectively. S P Gr ← S P G p S P Gr

(21)

Service process convergence has a huge impact on the consumer experience. Deep convergence provides consumers with a seamless service experience and improves service efficiency. Service process convergence is extremely complex due to the topological relationships between tasks in the service process. The relationship between the two service patterns should be considered, as summarized in Table 10. Table 10 reveals the logical relationships that may exist between two patterns. There are two main types of relationships: synchronous and serial. For a serial relationship, the implementation of the service pattern mainly has a before–after relationship, where seq = i indicates that pattern i is executed first. For synchronous execution, in which two patterns are in the same business phase, there are three categories of execution: exclusive, parallel, and contained. Exclusive execution means choosing one of the two to perform the task according to the judgment rules. In parallel execution, both modes start executing at the same time. In contained execution, one pattern can invoke another pattern for one or more tasks. Handling cases with sequential relationships is relatively simple. For serial cases, connecting two processes sequentially allows the entire service to run without logical errors. However, for two patterns at the same business stage, the solution can be more complex. In this case, there are two problems that need to be solved: identify similar tasks with different patterns to improve service efficiency and determine the correct order of task execution in the new convergence mode. Identifying similar tasks can Table 10 The relationship between two patterns

Sequence relationships

Logical relationships

Synchronous

Exclusive Parallel Include

Serial

seq = 1 seq = 2

Crossover Service Pattern: Modeling and Computing

61

improve process efficiency and reduce repetitive workloads. The similarity of the two tasks is determined based on the following criteria: • Performed by the same participants; • Supported by the same type of resources; • Have the same input and output types.

5.2 Experiment and Discussion To illustrate the advantages of this approach, we apply it to the convergence of an OTA and online insurance patterns. To reduce the amount of time spent queuing offline, OTAs enable travelers to book flights and hotels online. The convergence with insurance allows travelers not to worry about loss due to schedule changes. We chose Fliggy and Ant Insurance to implement this case study. Similar to Fliggy, Ant Insurance works with a number of insurance companies to provide policyholders with free and convenient choices and access to purchase insurance. According to the service pattern graph proposed above, these businesses can be represented by a diagram (Figs. 15 and 16). The red, green, blue, and yellow nodes represent the participant, resource, service target, and service process, respectively. As a result of the running phase, it is concluded that because value is generated during the review phase, the service objectives can reflect the value needs of the participants. Therefore, we do not consider value for the time being. In Figs. 15 and 16, nodes represent the key components of the service pattern, where different colors represent different categories of key components. Different relationships are represented as different types of edges. For Fliggy, consumers can

Fig. 15 Service process of Fliggy

62

J. Chen et al.

Fig. 16 Service process of Ant Insurance

select, submit, and pay for orders on the Fliggy platform, where the yellow node forms a complete service process. For Ant Financial Insurance, the service pattern provides a platform for users to purchase insurance through a simple transaction and for policyholders to apply for compensation online. For both patterns, participants, necessary resources, service values, and service goals are also represented by different color nodes. The diagrams for the two service patterns are compatible. The service pattern graph makes the node relationships clearer, improving the efficiency of pattern convergence. We apply the framework of Fliggy and Ant Financial Insurance to generate a new service that enables consumers to purchase insurance when booking tickets and hotels. Therefore, the two patterns are within the same stage and have a parallel relationship. seq = 0; r elation = parallel

(22)

In this new service, the participant mapping relationships are consumer → policyholder.

(23)

That is, Fliggy’s consumers can complete the tasks of Ant Financial insurance policyholders. The result of applying these algorithms is a new pattern for the convergence of Fliggy and Ant Insurance, as shown in Fig. 17. In the new pattern, the topological relationships of the tasks are preserved. Tickets and travel insurance can be selected at the same time. In addition to the actual use case, we apply our approach to the rule-generated dataset of service patterns. The dataset contains 64 service pattern files in the form

Crossover Service Pattern: Modeling and Computing

(a) Fliggy

63

(b) Ant Insurance

(c) New pattern Fig. 17 Service pattern graph for Fliggy, Ant insurance and new merged one © [2022] IEEE. Reprinted, with permission, from Ref. [5304030122479]

of BPMN, each with more than 700 nodes when converted to a service pattern graph. Combine the first service pattern with the remaining 63 service patterns to calculate the compression ratio at different similarity parameter thresholds. The compression ratio is calculated as compression Ratio = 1 −

Nnew Noriginal

(24)

and represents the sum of the nodes or edges of the two original service pattern graphs, which is the number of nodes or edges in the new service pattern graph. Values for θ include 0.4, 0.5, 0.6, and 0.7. Figure 18 shows the node-compression and edge-compression ratios at different θ values. According to the results, the larger the value of θ, the higher the similarity requirements, resulting in a lower compression ratio.

64

J. Chen et al.

Fig. 18 Compression ratio for nodes and edges under different values of theta © [2022] IEEE. Reprinted, with permission, from Ref. [5304030122479]

In the original schema, business constraints are represented as relationships. The new pattern provides a prototype of services for OTAs and the insurance industry. Comparisons with other methods are provided in Table 11. Compared to the other two approaches, our framework accounts for the convergence of participants, resources, and service processes, effectively enabling the semiautomation of crossover service patterns. Size of the merge pattern. The more streamlined the pattern, the easier it is to understand. Therefore, the size of the pattern is an important indicator of the standard. In Table 12, the size of the new pattern has decreased and its node- and edge-compression ratios are 31.11 and 16.13%, respectively. For experiments on the resulting dataset, the compression ratio varies with the change in θ. However, as the business logic is preserved as much as possible, some redundant relationships are also preserved. For example, in the new pattern, consumers do not interact with the Ant Insurance platform; instead, all of the consumer’s online operations are performed on the Fliggy platform. Determining how to maximize compression without compromising business logic is a topic worthy of further effort.

Crossover Service Pattern: Modeling and Computing

65

Table 11 Comparison of several methods © [2022] IEEE. Reprinted, with permission, from Ref. [5304030122479] Convergence

Advantages

Disadvantages

Merging methods in Process convergence [15]

Consider semantic similarity; the merged model is compact while capturing all behaviors

Fail to consider the convergence of resources and participants; lacking deeper relationship mining

Business process Process convergence consolidation in [16]

Consider the topic of Fail to consider the process; extract process convergence of patterns resources and participants; lacking deeper relationship mining; weakened business semantics

Rule-based pattern convergence framework

Summarize general Lacking deeper rules; consider relationship mining semantic similarity; multi-level convergence

Participant convergence; resource convergence; participant convergence

Table 12 Pattern size © [2022] IEEE. Reprinted, with permission, from Ref. [5304030122479] G1

G2

New G

Compression ratio (%)

Node

22

23

31

31.11

Edge

43

50

78

16.13

6 Summary In this chapter, the background and challenges of crossover service pattern convergence are discussed. Then, we propose a technical framework of service pattern modeling and computation, based on which, we introduce the methods for service pattern modeling, simulation, evaluation, and convergence. For service pattern modeling, we propose a quantitative service pattern-description language based on four aspects of service patterns. To simulate the service pattern, we introduce a multiagent service pattern-simulation method based on the description model. Besides, a comprehensive set of evaluation metrics is proposed to achieve further assessment of service patterns. Finally, a rule-based service pattern-convergence framework is proposed that shows promising performance in typical case studies.

66

J. Chen et al.

References 1. Yin Y, Zhang R, Gao H, Xi M (2019) New retail business analysis and modeling: a Taobao case study. IEEE Trans Comput Soc Syst 6(5):1126–1137 2. Zhang R, Yin Y, Xi M, Jiang H (2018) Towards business identification modeling: a Taobao case study. In: SEKE, pp 17–22 3. Xi M, Yin J, Wei Y, Zhang M, Deng S, Li Y (2020) A scenario-based modeling method for crossover services. In: 2020 IEEE International conference on services computing (SCC). IEEE, pp 20–29 4. Joyce A, Paquin RL (2016) The triple layered business model canvas: a tool to design more sustainable business models. J Clean Prod 135:1474–1486 5. Barros O (2019) A process architecture pattern and its application to designing health services: emergency case. Bus Process Manag J 26(2):513–527 6. Li Y, Luo Z, Yin J, Xu L, Yin Y, Wu Z (2017) Enterprise pattern: integrating the business process into a unified enterprise model of modern service company. Enterp Inf Syst 11(1):37–57 7. Gao Z, Fan Y, Li X, Gu L, Wu C, Zhang J (2019) Discovery and analysis about the evolution of service composition patterns. J Web Eng 18(7):579–626 8. Luo Z, Li Y, Yin J, Gao H, Yin Y (2017) Service pattern evaluation: studying profitability from perspective of resource. In: 2017 IEEE International conference on cognitive computing (ICCC). IEEE, pp 88–95 9. Li Y, Xi M, Yin Y, Luo Z, Gao H, Yin J (2018) MeCo-TSM: multi-entity complex processoriented service modeling method. In: 2018 IEEE International conference on web services (ICWS). IEEE, pp 82–90 10. Yin J, Xi M, Deng S, Tan S, Chen J, Wei Y, Wu Z, Dustdar S (2022) A service pattern-oriented computing architecture for service ecosystems. IEEE Internet Comput 26(1):51–59 11. Chen J, Yin J, Xi M, Tan S, Wei Y, Deng S (2020) Service pattern modeling and simulation: a case study of rural Taobao. In: 2020 IEEE International conference on services computing (SCC). IEEE, pp 38–47 12. Yin J, Tan S, Xi M, Chen J, Wei Y, Deng S (2020) JTang Dubhe: a service pattern modeling and analysis system. In: 2020 IEEE International conference on services computing (SCC). IEEE, pp 438–445 13. Xi M,Yin J, Chen J, Li Y, Deng S (2021) Quantitative assessment of service pattern: framework, language, and metrics. IEEE Trans Serv Comput 15(6):3457–3470 14. Chen J, Yin J, Xi M, Tan S, Wei Y, Deng S (2020) A rule-based service pattern convergence framework for crossover service. In: 2020 International conference on service science (ICSS). IEEE, pp 16–22 15. Rosa ML, Dumas M, Uba R, Dijkman R (2010) Merging business process models. In: OTM Confederated international conferences “On the move to meaningful internet systems”. Springer, Berlin, Heidelberg, pp 96–113 16. Bani-Hani I, Tona O, Carlsson S (2020) Patterns of resource integration in the self-service approach to business analytics. In: Proceedings of the 53rd Hawaii international conference on system sciences, pp 1–10

Crossover Service Requirements: Analysis and Design Yu Qiao, Zhengli Liu, Jian Wang, and Bing Li

Abstract Crossover services often span multiple industry boundaries, and user requirements are typically diverse and personalized, leading to many challenges in requirements analysis and system design. In essence, crossover services are developed to meet user requirements across multiple domains. An approach of requirements convergence-analysis, design and evolution is proposed to support the convergence process in service requirements analysis and design. Keywords Crossover service requirements · Service design · Requirements evolution · Goal convergence · Process convergence Crossover services often span multiple industry boundaries, and user requirements are typically diverse and personalized, leading to many challenges in requirements analysis and system design [1]. In essence, crossover services are developed to meet user requirements across multiple domains; that is, the emergence of crossover services is caused by inability of some user requirements to be satisfied by the original domain, requiring support from other domains. It is thus necessary to converge the requirements models of the initial and new domains to obtain a unified and complete requirement model, which can effectively guide the development of crossover services. Stakeholders from different domains form a new value network. The target users may have unique goals and BPs that may differ from those in their original domains. To comprehensively understand the crossover requirements and Y. Qiao · J. Wang (B) · B. Li Wuhan University, Wuhan, China e-mail: [email protected] Y. Qiao e-mail: [email protected] B. Li e-mail: [email protected] Z. Liu Wuhan Textile University, Wuhan, China e-mail: [email protected] © Zhejiang University Press 2023 J. Yin et al. (eds.), Convergence in Crossover Service, Advanced Topics in Science and Technology in China 68, https://doi.org/10.1007/978-981-19-8844-8_3

67

68

Y. Qiao et al.

obtain feasible solutions to meet them, we need to define a unified metamodel to guide the modeling and convergence of service requirements in various domains. According to the proposed metamodel, crossover service requirement modeling is conducted from the perspectives of values, goals, and processes. In the crossover service requirements modeling process, we must converge the requirement models from multiple domains, as some user requirements may not be achieved by services developed for a single domain. In this chapter, corresponding methods are presented to guide goal and process convergence for crossover service requirement modeling. During crossover service requirements analysis, service requirements are ultimately modeled as process models, typically represented as BPMN diagrams. Next, the crossover service design serves as a bridge between the requirement analysis and service development. This chapter introduces a new model-transformation approach to generate a microservice-based design solution from BPMs expressed in BPMN. Requirements evolution is an essential topic in software development. In crossover services, the convergence process itself is also an evolution process. Because user requirements cannot be satisfied by a single domain, the original requirement models should be evolved into new ones by integrating the requirements and solutions from other domains. Based on the crossover requirement-evolution scenario, this chapter introduces population- and community-based crossover convergenceevolution patterns from an ecological perspective. Based on the proposed evolution patterns, a value-driven crossover service requirement-evolution method is proposed. The remainder of this chapter is organized as follows. A metamodel for crossover service requirement modeling is first proposed, followed by detailed induction of goal- and process-convergence analysis. Next, a microservice-oriented servicedesign approach is introduced based on the converged process model. Finally, requirement-evolution analysis of service ecosystems is discussed.

1 Metamodel for Crossover Service Requirements Modeling A metamodel for crossover service requirements modeling based on the characteristics of crossover services is proposed in this chapter. Details of the metamodel are illustrated as follows. Requirements modeling is a standard and essential topic in software engineering. Previously, many methods have been proposed to address the challenges of modeling diverse and personalized user requirements [2, 3]. For example, value-based requirements engineering methods [4], e.g., e3value [5], provide a mechanism to model the value-exchange relations among stakeholders. In addition to value-based methods, goal-based methods [6, 7] are commonly used requirement-modeling methods. However, the previous methods only provide a mechanism to describe stakeholders’ value-exchange relations or intentions in single-business scenarios and thus cannot fully cover the characteristics of crossover services. To better support crossover service modeling, the first task is to build practical modeling methods to model user requirements. In this chapter, the key elements involved in the crossover scenarios

Crossover Service Requirements: Analysis and Design

69

are extracted and a metamodel is proposed consisting of a service-value metamodel, service-goal metamodel, and service-process metamodel [8]. An overview of the metamodel mapping the relations among the three parts is shown in Fig. 1. The metamodel is composed of six fundamental elements. (1) The role is an expected behavior pattern or capability profile associated with participation in a specific organizational context. (2) The goal is a state that users expect a target software system to achieve. (3) A value object is the economic value for at least one participant. It is the content to be requested and exchanged among stakeholders [4]. (4) Value activity is a collection of operational activities that can be assigned to an actor [4]. (5) A process is a series of activities. (6) A service is a mechanism that uses the specified interface to access one or more functions according to the constraints and policies defined in the service description. More specifically, each role owns corresponding goals within an organization that represent their expectations and intentions. Goals can be achieved through value

Goal

Role owns

name organization

obtains

name type

uses achieves

Value Object produces

name type value interface provider consumer

Value Activity name executor

uses

defines Service name domain

Process realizes

Fig. 1 Overview of the proposed metamodel

name

70

Y. Qiao et al.

activities, which can be defined by a process. A role may use or obtain value objects during the execution of value activities. Value objects are produced and used during the execution of value activities. The functionalities defined by processes can be realized by services. The three metamodels are illustrated in the next subsections. A typical characteristic of crossover services is that each participant collaborates to create and exchange values in a business network. At the requirement-analysis stage, it is important to describe the value propositions of stakeholders and clarify the value-exchange mechanism to support the resulting service design. Therefore, this metamodel expresses the value propositions of stakeholders involved in the crossover service system. As shown in Fig. 2, the service value metamodel comprises the following elements: (1) “Participant” refers to a human participant or a software agent. Human participants can be classified into two categories: individuals and organizations, and each participant has two attributes: profile and context. The profile describes the internal static information that represents the essential characteristics of the participant, while the context describes how the participants interact with outside factors, such as an online platform or their environment. (2) The role denotes the responsibility that one or more participants take. Each participant can play one or more roles. (3) Each goal has two attributes: name and type. (4) A value activity is a collection of operational activities that can be assigned as a whole to actors and have two attributes: name and executor. A series of value activities should be performed to achieve one or more goals. The executor attribute indicates the participant who undertakes the activity. (5) A value object is valuable to one or more actors, and may be services, goods, money, or even consumer experience. It has five attributes: name, type, value interface, provider, and consumer. Type represents its category, such as tangible or intangible, and the value interface represents the payment channel. The provider and consumer represent the participants who provide and receive the value object, respectively. (6) A monetary value object is a value object assigned monetary value, such as money, goods, and services. (7) A nonmonetary value object is a value object that is difficult to assign monetary value, such as brand value, intellectual property, social value, and cultural value. In the proposed value-driven crossover service-design method, the value network analysis plays a fundamental role in the whole metamodel framework. The value network can be used to clarify the value propositions of stakeholders and describe the value-exchange mechanism among participants. In addition, it is helpful to explain the value-creation activities, establish the relations among value objects and goals, and then model the goals. A goal model can be used to capture the intentions of stakeholders to iteratively refine high-level goals into subgoals/tasks. When goals are first proposed in crossover service scenarios, they are usually coarse and need further refinement to clarify the execution tasks. To capture new target users’ intentions and requirements in the crossover service domain, a goal metamodel is proposed to model user requirements. As shown in Fig. 3, the service goal metamodel includes the (1) participant, (2) role, and (3) goal. Based on their completion criteria, goals can be divided into functional and nonfunctional goals. (4) The constraint types can be divided into two

Crossover Service Requirements: Analysis and Design

71 Value Object

plays 1..*

Role 0..*

1..*

name organization

Participant

uses

1..* obtains

0..* 0..*

1..*

0..*

0..*

produces

uses

1..*

1..*

profile context

name type value interface provider consumer

Monetary Value Object name

Non-monetary Value Object name

owns

1..*

Goal name type

0..*

achieves 1..*

Value Activity name executor

Fig. 2 The service value metamodel

categories: dependent and exclusive. Dependent means that the realization of one goal depends on another; that is, one goal can be achieved only if the goals upon which it depends can be achieved. Exclusivity indicates incompatibility between two goals; that is, the realization of one goal leads to the failure of another. (5) Decomposition of an upper goal into several lower goals is achieved with two relations: AND and OR. In AND decomposition relations, the upper goal can be achieved only if all the associated lower subgoals can be achieved. In this relationship, a lower goal is usually a part of the upper goal. An OR decomposition relationship mean that the upper goal can be achieved if any one of the lower subgoals associated with it can be achieved. In this relation, the lower goal is usually an alternative method to achieve the upper goal. (6) A functional goal refers to the functional requirements that the service under development needs to meet, which can be achieved through a specific process. It has four attributes: operation, object, manner, and is_operational. The operation attribute denotes the action performed by the role. The object represents the entities of the goal operation. The manner denotes how goal operations are applied to the object, and is_operational refers to whether the goal is operational. Here, an operational goal is defined as a goal that can be directly achieved by a human or IT service. (7) A nonfunctional goal describes the nonfunctional attributes of the service under development. Nonfunctional goals cannot be directly realized and their evaluation criteria are usually subjective. A nonfunctional goal can be divided into quantitative and qualitative goals and have one attribute, type, which includes classifications such as security, reliability, and price.

72

Y. Qiao et al. Constraint

0..*

hasConstraint

Functional Goal

type 0..* Role

0..* owns

Goal

0..*

name organization

is_operational manner object operation

name type

1..*

0..* hasDecomposition

Non-functional Goal type

plays 1..* Participant profile context

0..* Decomposition type

Fig. 3 The service goal metamodel

When first proposed, a goal is usually coarse and high-level. These high-level goals need to be further decomposed into finer goals to facilitate the adoption and composition of services to achieve them. This decomposition process does not end until all the leaf-level goals are operational. Because user requirements are usually complex and volatile, it is often necessary to orchestrate multiple services to achieve user requirements. Crossover services provide services for many domains and thus require the collaboration of services from those domains. These services and their invocation relations form a complex service network. To solve the problems of crossover service process modeling, a service process metamodel is proposed to support modeling the process orchestration and service interaction. As shown in Fig. 4, the service process metamodel includes the (1) value activity, (2) goal, and (3) process. A process refers to a group of connected activities according to a particular logical relationship to accomplish a specific task. According to the granularity of the task, the process can be divided into atomic and composite processes. (4) An atomic process has indivisible granularity, whereas (5) composite processes comprise more than one atomic process. The operation mode of these processes is defined by the composition type, which represents the execution mode of the process. There are four composition types: sequence, selection, concurrency, and loop. The metamodel also includes the (6) service itself, as well as the (7) service operation, which expresses the functional capability of a service. Each service operation refers to an execution of the service and has one attribute: name. (8) The input message is the input information the service operation needs for its execution, and (9) the output message denotes the output information after successfully executing the service operation. Finally, (10) the resource indicates the information to be created and consumed in the execution of a process.

Crossover Service Requirements: Analysis and Design 0..*

Value Activity

1..* realizes

73

0..*

name executor

Input Message name type

name 0..* 0..* consumes 1..*

defines

Composite Process

Resource

0..*

0..*

creates

name

1..1

consumes 0..*

0..*

0..*

composes 1..* Service

0..*

Process name

Service Operation

composite type

name

1..*

achieves

Atomic Process

0..*

realizes

0..*

name domain quality provider

contains 1..1

1..*

generates

0..* Output Message name

Fig. 4 The service process metamodel

The crossover scenario that the proposed approach attempts to address is described by the following example. Suppose that a service belonging to a specific domain already exists. The service providers plan to enlarge their value chain by extending their services to other domains, providing a crossover service to cover more fields. The proposed approach aims to facilitate requirement modeling and analysis during the development of such crossover services. The modeling process based on the proposed metamodel comprises the following steps. (1) Identifying the domain. Before constructing the value model, the subject and object domains must first be identified. (2) Identifying participants and roles. Once the domain is determined, the requirement analyst can identify the participants and roles in the crossover scenario and obtain a list of participants and roles. After repeated refinement and revision, an accurate list of participants and roles is finally obtained. (3) Analyzing value objects and value activities. According to the list of participants and roles, the activities and value objects that each role should perform in the crossover scenarios are analyzed. (4) Constructing a value model. After defining the element instances required by the value model, requirement analysts can build the value model. (5) Constructing a goal model. Starting from the value model, the objectives of each role are analyzed, the large-scale goals are decomposed according to the decomposition relations and constraint relations defined by the goal metamodel, and the constraint relations among goals are established. In this manner, a corresponding goal model can be built. (6) Constructing a service process model. Requirement engineers analyze what processes are needed to achieve the goals of each role and what services are necessary to realize those processes. Thus, a service process model can be built.

74

Y. Qiao et al.

2 Convergence Analysis of Service Requirements In a traditional service scenario, services are developed to meet user requirements in a single domain. However, user requirements constantly evolve, and the service of an initial domain may fail to meet some emerging user requirements or goals. The goal to be converged is a new emerging goal that cannot be satisfied in the initial domain. Although such goals cannot be satisfied in the current domain, potential solutions in other domains can be leveraged. We call the domain that generates goals for convergence a subject domain and the domain with potential solutions to satisfy those goals an object domain. This requires that the goal model of the subject domain be deeply converged with that of the object domain. Because the service requirements of each domain have unique characteristics and constraints differ across business areas, conflicts inevitably arise during the convergence process. Therefore, a method is needed to guide goal convergence for crossover services.

2.1 Goal Convergence of Crossover Services Crossover scenarios involve the synergy of many different domain organizations. In the requirement-analysis process, the goals of various domain actors need to be deeply integrated. These scenarios involve a wide range of stakeholders in different domains whose goals are prone to conflict during the convergence process. However, traditional goal-based modeling methods rely on time-consuming and inefficient manual work to identify the conflicting dependencies among goals. Developers need to master domain knowledge and expend substantial effort to create goal models. Therefore, it is essential to achieve automatic goal convergence that supports goal-conflict resolution to improve the efficiency of requirement modeling in the requirement analysis of crossover services. The goal model convergence framework is shown in Fig. 5. The primary domain goal-model repository is constructed according to the domain knowledge. Community- or population-based crossover service goal-convergence approaches are selected according to different convergence design patterns. Here, some definitions are provided. Definition 1 Functional goal = {function goal verb, function goal noun, verb related preposition, noun related preposition}. Definition 2 Aggregated goal = {aggregate goal verb, aggregate goal noun, left modifier set of nouns, right modifier set of nouns, verb related preposition, noun related preposition}. Definition 3 Goal model = {actor, goal, relationship, resource}. This is formally expressed as GM = , where act is an actor, g is a goal, rel is a relationship, and res is a resource. A goal model contains one or more actors whose

Crossover Service Requirements: Analysis and Design

75

Fig. 5 Overview of the proposed goal model convergence approach

intentionality is expressed through actor boundaries, which are graphic containers of the actors’ goals and relationships. Goals include functional, nonfunctional, and operational goals. Relationships include internal (AND, OR, Dependency, Exclusion, Help, and Hurt) and external (Dependency) relationships among actors. An actor is dependent on another through a resource. An actor that depends on the resource is called a depender, while the actor that provides the resource is called a dependee. (1) Community-based crossover service goal convergence A community-based crossover service usually manifests as the horizontal extension of services. The provider of the main service integrates with other services across domain boundaries based on core services in a manner similar to the aggregation relationship. Initial services are often oriented to a single domain, but the user requirements continuously evolve, resulting in new user requirements that cannot be met. Although these requirements cannot be completed in the current domain, other

76

Y. Qiao et al.

domains may have solutions. To facilitate differentiation, the following definitions are established: Definition 4 To-be-converged goal (cg): a new goal that cannot be satisfied by the current domain’s goal model because of the evolution of requirements. Definition 5 Subject domain: the domain that produces the to-be-converged goal. Definition 6 Object domain: the domain where a set of goals can satisfy the to-beconverged goal. The community-based crossover service goal-convergence method is to converge the goal set existing in the object domain into the subject domain to meet the to-beconverged goal [9]. As shown in Fig. 6, the community-based crossover service goal-convergence method can be divided into three stages: 1. Reconstruction of goal models in the subject domain In the subject-domain goal model (SDGM), the new user requirements cannot yet be met, so the to-be-converged goal is generated. The SDGM is reconstructed according to the user’s to-be-converged goal, which can be divided into two steps: Step 1: Add the to-be-converged goal of the user. Through analysis of the SDGM, the actors in the model, the actors’ goals, and the dependencies among the actors are determined. Then, under the guidance of a domain expert, the user’s to-be-converged goal is added to the appropriate position in the goal-model fragment of the user. Step 2: Add the to-be-converged goal of the main service provider. When a user produces a to-be-converged goal, the main service of the user’s depender in the goal model of this domain also proposes a to-be-converged goal to meet it, which is also unsatisfied initially. The to-be-converged goal of the main service is added to the appropriate position in the corresponding fragment of the goal model of the main service, and the reconstructed goal model of the main domain is obtained. 2. Matching of goal models in the object domain After reconstruction, the object-domain goal model (ODGM) can be matched in the domain goal-model repository by utilizing the to-be-converged goal of the user from the SDGM. First, semantic similarity matching is performed between the user’s to-beconverged goal in the SDGM and the goal model in the domain goal-model repository. Then, g and RDKL of any domain goal model GM in the domain goal-model repository are preprocessed by word segmentation, form reduction, frequency statistics, and stop-word removal. Finally, the equation to calculate the cosine similarity of g and GM is defined as ∑n (xi · yi ) , (1) Sim(g, GM ) = /∑ i=1 /∑ n n 2 2 i=1 xi · i=1 yi

Crossover Service Requirements: Analysis and Design

77

Fig. 6 Overview of the community-based goal model convergence approach

where {x1 , x2 , . . . , xn } and {y1 , y2 , . . . , yn } are the word-frequency vectors of g and GM, respectively. If Sim(g, GM ) exceeds the threshold set by domain experts, GM can be added to the ranked similar domain goal list in descending order of similarity. Then, it can match the ODGM by similarity calculation. In the matching process, a knowledge graph can also be used to learn the low-dimensional vector representation of the goal and its relationship based on deep learning and the semantic distance between the parent and child goals can be as close as possible by the learned embedding representations. 3. Convergence of subject and ODGMs The convergence of the subject and ODGMs, which contains the convergence of the user goal model fragment and the depender goal model, is to satisfy the to-beconverged goal of the subject domain.

78

Y. Qiao et al.

After the user’s to-be-converged goal has been determined in the SDGM, the child goal set of the corresponding goal in the ODGM should be converged into the SDGM according to the rules to satisfy the to-be-converged goal of the user. In the goal model, the satisfaction of user goals is usually dependent on the role of dependers, especially the main service providers. Thus, it is necessary to determine the main service provider and converge the goal model fragment of the main service provider according to the user dependencies in the two goal models. First, the set of dependers on which the subset of similar goals depends is determined and added to the SDGM according to the dependency relationship among actors in the ODGM. Then, the main service providers in the two domain goal models are identified. In the SDGM, the main service providers generate the to-be-converged goal according to that generated by users. In the ODGM, the main service is the main role that satisfies the children’s goal set of a similar goal. Next, we converge the two-domain main service goal model fragments according to the defined convergence rules and redefine users and their dependencies. In other words, users depend on the main service providers of the SDGM, which in turn rely on the main service providers of the ODGM. Finally, a crossover service goal can be generated to satisfy the crossover service goal model using the advice of domain experts and knowledge of the domain context. (2) Population-based crossover service goal convergence Population-based crossover convergence is a vertical derivation of services, which is the process of deriving new similar services based on the core services of the main service provider in the initial (subject) domain to meet the business needs of other (object) domains. In the population-based crossover service design pattern, there is a derivative relationship among the new user goals evolved from the SDGM and the existing user goals of service consumers. The user goal model fragments in the SDGM derive new user goals of the same type. In the set of dependers upon which users depend, the main service providers also derive new similar services and finally converge the new domain goal model according to the final derived new services. Some definitions are given as follows: Definition 7 Initial user goal: A user goal that can derive similar user requirements in the SDGM. Definition 8 User-derived goal: A goal generated by the user’s newly derived requirements. Definition 9 Initial service goal: A service goal provided by the main service provider in the SDGM. It can satisfy the initial user goal. Definition 10 Service-derived goal: A derived service goal that can satisfy the user-derived goal. Definition 11 Domain-derived goal model: The goal model of the related domain that the service-derived goal matches.

Crossover Service Requirements: Analysis and Design

79

Fig. 7 Overview of the population-based goal convergence approach

Figure 7 shows the framework of the population-based crossover service goal convergence approach, which has three components. 1. Derive user goal model fragment This component determines the initial user goal by analyzing the user goal model fragment of the SDGM to derive the user-derived goal model fragment from top to bottom. The user-derived and initial user goal model fragments form the new user goal model fragment. 2. Derive depender goal model fragment When a user derives a fragment of the goal model, the main service provider in the depender sets relied upon by users derives new similar services to satisfy the userderived goal model fragment, and the depender of the main service also derives a new goal model fragment. The domain goal model can derive new goal model fragments based on the relationship among actors. 3. Converge domain-derived goal model The user-derived goal model fragment can be derived by the new requirements of the same services, and the service-derived goal model fragment can be derived from the user-derived goal model fragment based on the SDGM. We denote the domainderived goal model as the goal model of another domain that can satisfy the servicederived goal model. The domain-derived goal model can provide the dependencies required by the service-derived goal model in the SDGM to complete some basic services in the target domains. Therefore, it is necessary to match the domain-derived goal model according to the fragments of the service-derived goal model and converge

80

Y. Qiao et al.

the SDGM with the domain-derived goal model to obtain the convergence crossover service goal model. First, we extract keywords from the service-derived goal model using the term frequency–inverse document frequency algorithm. Then, we select n keywords of the initial service goal model fragment in descending order of word weight, where n is set by domain experts. Next, we match the service-derived goal model in the domain goal-model repository to the keyword list selected in the service-derived goal model fragment. If the semantic similarity of the keywords list and a goal model in the domain goal-model repository is greater than a threshold, and the goal model can satisfy the initial service goal model fragment, the service-derived goal model can be matched. Finally, we converge the matched service-derived goal model with the SDGM. The final convergence crossover service goal model is obtained after the user goal fragment satisfying the initial service goal model fragment and the dependency relationship are added to the SDGM.

2.2 Process Convergence of Crossover Services Crossover service convergence design aims to expand business boundaries and realize value-added services by integrating cross-domain services. At the processconvergence level, community- and population-based process convergence are investigated. The community-based process-convergence approach focuses on the expansion to other domains and reflects a horizontal aggregation relationship of same-level services. The cooperation of services in different domains enables the expansion of core business service capabilities in the current domain. In contrast, the populationbased process-convergence approach mainly focuses on deriving the same type of service, which is a vertical generalization relationship. This process reflects the crossdomain derivative capability of the main service. Generally speaking, two aspects of the convergence process should be considered. First, changes in message flows should be considered. The original BP changes, which means that the elements and relationships of message flow among active nodes are rearranged. Therefore, we should break the original boundary and refactor the process structure from the perspective of message flows. Second, different roles and goals may have different influences on process convergence. Crossover service convergence often involves multiple roles in multiple domains. Coordinating different goals among these roles and achieving a win–win situation is a challenging problem.

Crossover Service Requirements: Analysis and Design

81

Fig. 8 Overview of the process-convergence framework

This chapter focuses on the community-based process-convergence approach [10]. The approach first partitions service process models into multiple process fragments through message flow segmentation and then devises convergence rules for the process fragments. A new process model that meets the convergence goal of the crossover service can thus be generated. As shown in Fig. 8, the proposed convergence framework consists of four steps: decomposition of process models, determination of mergeable fragment pairs, convergence according to the convergence rules, and integration of the remaining fragments. A. Decomposition of Crossover Service Process Model Crossover services generally involve multiple roles (e.g., various stakeholders or organizations within enterprises) and BPs in different domains. Accordingly, decomposition of the process models based on message flows should ensure that the roles involved in the subprocess fragments (SPFs) are the same and retain the fragment’s own original constraints. 1. Message flow annotation The message and sequence flows in a BP indicate the relations and structures among activities, gateways, and other process elements. Therefore, it is helpful to rebuild the structure of a newly converged process model by identifying the message flow among different roles.

82

Y. Qiao et al.

2. Decomposition strategies The decomposition rules are defined as follows: (1) All activities in an SPF belong to the same role. (2) The SPF may contain multiple source nodes and multiple sink nodes. There is no restriction on the number or type of message flow. (3) The flow objects connected only to SPFs are message flows. Definition 12 Convergence subject and object: Suppose the purpose of process convergence is that role A expands role B’s business into its business system. In that case, A and B are the convergence subject and object, respectively. Definition 13 Subprocess fragment: SPF = (N, E, SR, AR, G, PreF, PostF), where N is a set of nodes in SPF, E is a set of edges (i.e., sequence flows) in SPF, SR is the subordinate role to which an SPF belongs, AR is the role that directly interacts with the SPF using a message flow, G represents the goal that SR aims to achieve by executing the SPF, PreF refers to the fragment that has a message flow with the source node of the SPF, and PostF refers to the fragment that has a message flow with the sink node of the SPF. Each flow object (e.g., an event, activity, or gateway) is regarded as a node in the BPM. Please note that the nodes in an SPF can be divided into three categories: source, intermediate, and sink nodes. A source node refers to the segment’s nodes with outputs but no inputs. An intermediate node is a node in a BP segment with both input and output information. Finally, a sink node refers to a node in a fragment that has input but no output information. This chapter defines five types of process fragments, as listed in Table 1. B. Obtain Mergeable Fragment Pairs This step determines where two process models can converge. The candidate fragment pairs that can be converged are first obtained according to their roles. Then, the mergeable fragment pairs can be found based on their similarity. 1. Obtain candidate fragment pairs If the roles that two process fragments subordinate and their associated roles are different, the relevance between the roles executing the two process fragments is very small. In addition, the similarity between the goals and descriptions of two process fragments is often very low. Therefore, the role tags can be filtered to obtain the candidate process fragment pairs as convergence points. The definition of a candidate fragment pair is given below. Definition 14 Candidate fragment pair: A candidate fragment pair (fa , fb ) is an SPF pair from different process models that have the same subordinate or associated roles.

Crossover Service Requirements: Analysis and Design

83

Table 1 Types of subprocess fragments © [2022] IEEE. Reprinted, with permission, from Ref. [5319660203214] Type

Features

Gateway

Sequence

A sequence consists of activity None nodes and has no gateway. It has exactly one input and one output message flow

SEME (single-entry-multi-exit)

It has multiple output message It has at least one divergence flows but only one input message gateway flow

MESE (multi-entry-single-exit)

It has multiple input message flows and only one output message flow

It has at least one convergence gateway

SESE (single-entry-single-exit)

It has only one input message flow and one output message flow

It has at least one divergence and one convergence gateway

MEME (multi-entry-multi-exit)

It has multiple input message flows and multiple output message flows

It has at least one divergence and one convergence gateway

Given two BPMs P1 and P2 to be converged, for each SPF decomposed from P1 and P2 , if there is a fragment pair (fa , fb ), fa = = (Na , Ea , SRa , ARa , Ga , PreF a , PosF a ) ∈ P1 and fb (Nb , Eb , SRb , ARb , Gb , PreF b , PosF b ) ∈ P2 , where SRa = SRb or ARa = ARb , then (fa , fb ) is regarded as a candidate fragment pair W (fa , fb ). 2. Obtain mergeable fragment pairs Because different SPFs have different business goals, not all SPFs can be converged in crossover service scenarios. Therefore, the following strategy is designed to obtain mergeable fragment pairs. Definition 15 Mergeable fragment pair: A mergeable fragment pair is a fragment pair to be converged. If the similarity between fa and fb in W (fa , f b ) meets a given threshold, W (fa , f b ) can be considered a mergeable fragment pair M (fa , fb ). If the fragments in a candidate fragment pair meet at least one of the following conditions, the candidate fragment pair can be regarded as a mergeable fragment pair: (1) The semantic similarity between the input and output message flows of the fragments in candidate fragment pair is greater than the threshold. (2) The similarity between the SPFs is greater than the threshold. In this way, the mergeable fragment pairs can be filtered according to the convergence similarity calculated by the aforementioned similarities between the message flow and SPFs.

84

Y. Qiao et al.

The convergence similarity calculation is defined below. (a) Message-Flow Similarity: A message flow can reflect the original business behavioral constraints of process goals to some extent. The message-flow similarity between f1 and f2 is calculated by ) ( ) ( out MessSim(f1 , f2 ) = SynSim Mfin1 , Mfin2 + SynSim Mfout 1 , Mf 2 ,

(2)

where Mfin1 and Mfin2 are the input message-flow annotations of f1 and f2 , respecout tively, and Mfout 1 and Mf 2 are the corresponding output message-flow annotations. The SynSim function represents the syntax similarity, which is defined as Eq. 3. (b) Subprocess-Fragment Similarity: The syntax similarity between descriptions of activities can be calculated as SynSim(Des1 , Des2 ) = 1 −

ed (Des1 , Des2 ) , max(|Des1 |, |Des2 |)

(3)

where Des1 and Des2 denote the descriptions of activities, ed (Des1 , Des2 ) indicates their edit distance, and max(|Des1 |, |Des2 |) denotes the maximum number of words between the descriptions. If SynSim(Des ( 1 , Des2 ) > α (α )is a threshold), there exists a mapping relationship Map1−1 activity1 , activity2 . The similarity between SPFs can be obtained by Sim(f1 , f2 ) = ω1 ·

2 · |MappedActivities| + ω2 · SynSim(G1 , G2 ), |f1 .node| + |f2 .node|

(4)

where ω1 and ω2 are weighting factors, ω1 +ω2 = 1. |MappedActivities| denotes the number of activities with a Map1–1 mapping relationship, and |f1 .node| and |f2 .node| are the node numbers of SPFs f1 and f2 , respectively. SynSim(G1 , G2 ) denotes the syntax similarity between goals G1 and G2 . The convergence similarity between f1 and f2 can be calculated as fsim(f1 , f2 ) = ϕ1 · Sim(f1 , f2 ) + ϕ2 · MessSim(f1 , f2 ),

(5)

where ϕ1 and ϕ2 are weighting factors, ϕ1 + ϕ2 = 1. C. Convergence Strategies Given a mergeable fragment pair M (f 1 , f2 ), where f1 and f2 subordinate to the convergence subject and object, respectively, convergence strategies, including convergence rules and convergence operations, are defined. To converge a new process model based on fragments in different domains, we provide two convergence strategies:

Crossover Service Requirements: Analysis and Design

85

merge and insert. In the merge strategy, multiple fragments are converged into one fragment, while the insert strategy operates on the principle of placing multiple fragments for the current model into the proper structural position without changing the fragments. 1. Convergence Rules (a) Rule 1 (Merge). For each M (f 1 , f2 ), if there exists a mapping between activities of f1 and f2 , f1 and f2 are a set of process fragments that can achieve similar or identical functions or goals. f1 and f2 can be directly merged into one process fragment; in other words, one of these two fragments can be removed. If n1 ∈ f1 , n2 ∈ f2 , n1 , n2 ∈ Map1−1 (f1 , f2 ), and n1 .role and n2 .role are the convergence subject and object, respectively, then n1 is kept instead of n2 , the predecessor of n2 .successor is replaced with n1 , the successor node of n2 .predecessor is replaced with n1 , and n1 is inserted into the node set of a new fragment NF f1 ,f2 after the convergence from f1 and f2 . If n1 , n2 ∈ Map1−0 (f1 , f2 ), node n1 is inserted into node set NF f1 ,f2 . If n1 , n2 ∈ Map0−1 (f1 , f2 ), node n2 is inserted into node set NF f1 ,f2 . (b) Rule 2 (Insert). If there is no mapping between f1 and f2 in M (f1 , f2 ), the fragment subordinate to the convergence subject (e.g., f1 ) can perform functions or goals of the fragment subordinate to the convergence object (e.g., f2 ). Thus, f2 is directly inserted into the appropriate position in f1 . At this point, all nodes in fragments f1 and f2 are inserted into the node set of the convergence result NF (f1 ,f2 ) . 2. Convergence Operations After converging all the mergeable fragment pairs, all remaining SPFs can be converged by executing the convergence operations to obtain a complete process model according to the message and sequence flow. Based on Ref. [11], this chapter uses a correlation matrix between SPFs to obtain the structure of the process model. As shown in Table 2, if fi has a message flow to fj , the cell in row fi and column fj is marked as 1; otherwise, it is marked 0. Table 2 Subprocess fragment correlation matrix © [2022] IEEE. Reprinted, with permission, from Ref. [5319660203214] Start

f1

f2

f3

End

Start

0

1

1

0

0

f1

0

0

0

1

0

f2

0

0

0

1

0

f3

0

0

0

0

1

86

Y. Qiao et al.

(a) Operation 1 (Parallel convergence). Parallel gateways are added to the input path of the SPFs that have multiple input message flows through a single source node, and parallel gateways are added to the output path of SPFs that have multiple output message flows through a single sink node. As shown in Table 2, the start node has two outputs to f1 and f2 , so the sequence paths are (start, f1 ) and (start, f2 ), respectively, which should be evolved into (start, gate1, f1 ) and (start, gate1, f2 ) under parallel convergence. Similarly, SPF f3 has two inputs from f1 and f2 with original input paths (f1 , f3 ) and (f2 , f3 ). It should be evolved into (f1 , gate2, f3 ) and (f2 , gate2, f3 ). (b) Operation 2 (Serial convergence). This operation concatenates SPFs according to their message and sequence flows. Take the SPFs in Table 2 as an example. If f1 , f3 ∈ A(convergence subject), f2 , f3 ∈ B(convergence object), and f3 and “Start” are the NF (fi ,fj ) of mergeable fragment pairs M (fi , fj ), then there are SPFs f1 and f2 between f3 and the “start” node. Under the serial convergence operation, the concatenation of f1 and f2 is directly changed, that is, the successor of f1 is changed to f2 , and the predecessor of f2 is changed to f1 . D. Convergence Strategies This chapter uses Fliggy, a one-stop travel service platform that provides reservation services, such as tickets, hotels, visas, and car rentals, as an example. When consumers use these reservation services for traveling, they may fail to place an order or use the order on time, which results in inconvenience or financial losses. Therefore, the Fliggy platform hopes to converge some insurance-booking services into the original platform business and provide users with helpful insurance types, such as hotel-cancellation or flight-delay insurance. This chapter first constructs the BP models of Fliggy and an insurance company. Then, the BPMs and message flow annotations are shown in Fig. 9. SPFs can be obtained according to the decomposition strategies above, as shown in the highlighted part of Fig. 9. For example, because nodes “Browse hotel information” and “Select hotel and submit order” subordinate to the same role “user” and these two nodes have no gateway, they can be decomposed into fragment “s1-fz.” Similarly, fragments “s2-fz,” “s3-fz,” and “s4-fz” can also be obtained. In this case, the convergence subject is the Fliggy platform, and the convergence object is the insurance company. As shown in Fig. 10, for a mergeable fragment pair (s2-fz, s4-bx)), t1 , t3 ∈ Map1−1 (s2-fz, s4-bx), t2 , t5 ∈ Map1−1 (s2-fz, s4-bx), t4 ∈ Map0−1 (s2-fz, s4-bx). According to convergence rule 1, t1 and t2 are kept. Then the predecessor of t3 .successor is replaced with t1 , the successor node of t5 .predecessor is replaced with t2 , and t1 ,t2 , and t4 are added to node set m-s1(NF). Similarly, m-ss1 can be obtained by convergence rule 2, as shown in Fig. 11. After the direct relationships among all nodes and edges are analyzed, the structure of the SPFs can be obtained, as shown in Fig. 12. The convergence operations determine structures of fragments. Under parallel convergence operations, SPF “m-ss1” has output message flows through two different

Crossover Service Requirements: Analysis and Design

87

Fig. 9 Decomposition of BP models (the left is a Fliggy BP model, and the right is an insurance BP model) © [2022] IEEE. Reprinted, with permission, from Ref. [5319660203214]

sink nodes rather than one, so we only add a parallel gateway after the “start” node. Its original output paths are (start, s1-fz) and (start, s1-bx), which evolve into (start, gate1, s1-fz) and (start, gate1, s1-bx). Similarly, there are multiple input message flows of “m-s1” and “m-ss1.” Because “m-ss1” has input message flows through two different source nodes, we only add a parallel gateway before “m-s1.” The original input paths are (s1-fz, m-s1) and (s3-bx, m-s1), which have evolved into (s1-fz, gate2, m-s1) and (s3-bx, gate2, m-s1), respectively. The parallel convergence result is shown in Fig. 13a. Under serial convergence operations, SPFs “s1-fz,” “s1-bx,” “s2-bx,” and “s3bx,” exist between merged fragments “start” and “m-s1.” Fragment “s1-fz” belongs to the Fliggy platform, and “s1-bx,” “s2-bx,” and “s3-bx” belong to the insurance company. Therefore, we change the successor node of “s1-fz” to “s1-bx” and change the predecessor node of “s1-bx” to “s1-fz.” The convergence result of these SPFs is shown in Fig. 13b.

88

Y. Qiao et al.

(a) Mergeable fragment pairs before convergence

（b）New fragment after convergence Fig. 10 Example of convergence according to convergence rule 1 © [2022] IEEE. Reprinted, with permission, from Ref. [5319660203214]

(a) Mergeable fragment pair before convergence

（b）New fragment after convergence Fig. 11 Example of convergence according to the convergence rule 1 © [2022] IEEE. Reprinted, with permission, from Ref. [5319660203214]

Crossover Service Requirements: Analysis and Design

89

Fig. 12 Subprocess fragment structure © [2022] IEEE. Reprinted, with permission, from Ref. [5319660203214]

(a) Parallel convergence result

(b) Serial convergence result Fig. 13 Complete process model after using convergence operations © [2022] IEEE. Reprinted, with permission, from Ref. [5319660203214]

According to the context of this case, the operation of serial convergence is used. Figure 14 shows the final process model after process convergence.

3 Crossover Service Design As a widely used engineering technology, software modeling, drawing the system’s blueprint, is a key design activity before software realization. It also serves as a bridge between system requirements and system implementation. Developers can obtain an in-depth understanding of the overall system structure from the software model, thus shortening the development cycle and improving development quality [12, 13]. In the previous section, the crossover service requirements are modeled as service process models, typically represented by BPMN diagrams. The next step is to perform service design, which serves as a bridge between crossover service requirement analysis and service development. Experienced engineers usually need to refer to BPMN diagrams and Unified Modeling Language (UML) sequence diagrams (SDs) in software design and development. BPMN can be used to build easy-to-read BPMs, which can be shared across organizations and industries [14]. Modeling symbols in BPMN diagrams are categorized into four groups: flow objects, connecting objects, swim lanes, and artifacts. In

90

Y. Qiao et al.

Fig. 14 The converged process model © [2022] IEEE. Reprinted, with permission, from Ref. [5319660203214]

the development of an information system, BPMN models can be seen as the backbone of the system requirements. In other words, the BPs defined in the enterprise’s BPMN models can be leveraged to gather and identify the system requirements. SDs show object interactions arranged in temporally during software modeling [15]. It depicts how the objects are involved in a given scenario by describing the sequence of messages exchanged among them. SDs are typically associated with use-case realizations in the logical perspective of the system under development, and the development of crossover services is no exception. The increasingly popular microservice-based architecture becomes the foundation of crossover service realization. By following the UML SD, developers can design a microservice system with a reasonable and scalable architecture in the crossover service.

Crossover Service Requirements: Analysis and Design

91

However, there is currently no aided solution to help people design semiautomated or automated software. In particular, designers often need to gradually refine service requirement analysis and carry out cumbersome modeling and design manually, which has become a bottleneck for software development [16], particularly the development of crossover services. To address this problem, this section introduces a new model-transformation approach to generate a microservice-based design solution from BPMs expressed in BPMN. Specifically, this section proposes a scheme that converts BPMN diagrams to UML SDs using predetermined rules and a microservice design scheme based on UML SDs.

3.1 Design Procedure This section describes the microservice-design method based on BPMs. (1) First, BP diagrams are transformed into BPMN engineering models; (2) then, each BPMN engineering model is transformed into a UML SD; (3) the UML SDs are converted into external storage models for subsequent modification by designers as needed. To support this process, some image rules are defined. (4) Finally, transformation rules are used to analyze the UML sequence-engineering model for microservice design, and some code rules are defined to support the process. Figure 15 shows the overall procedure, where Steps (1) and (3) are code-level transformations that are described further in this text. Steps (2) and (4) involve specific transformation rules, which are described in detail.

Fig. 15 Overview of the transformation method

92

Y. Qiao et al.

3.2 Transformation from BPMN Models to UML SDs In software development, it is usually necessary to design UML SDs based on BPMN diagrams to assist with subsequent software design and development. This section proposes some transformation rules to automate the transformation from BPMN models to UML SDs. R1. Each swimming pool or lane is transferred to the corresponding actor that has the same lane name in the UML SD. That is, for a swimming pool or lane in the BPMN engineering model, a one-to-one transformation is defined to obtain a participant in SD. R2. For each service task performed in a lane, a transformation is made according to whether the source and target of the service task belong to the same lane. R2.1. If the source and target of the service task belong to the same lane, we add a new synchronous message from the actor corresponding to the lane generated by R1 to the actor corresponding to the pool generated by R1. The message name is the task name. R2.2. If the source and target of the service task belong to different lanes, we add a new synchronous message from the actor corresponding to the original lane to the actor corresponding to the target lane. The message name is the task name. R3. For each manual task performed in the lane, we add a new self-message to and from the same actor corresponding to the lane generated by R1. The message name is the task name. R4. For each script task performed in the lane, we add a new synchronous message from the actor corresponding to the lane already generated by R1 to the actor corresponding to the target lane generated by R1. The message name is the task name. R5. For each parallel gateway performed in the lane, we add an interaction operator “par” with a combined frame, where each par frame has the same number of operands to the outgoing flows of the parallel gateway. As illustrated in Fig. 16, each BPMN parallel gateway structure shown on the left side of the figure is converted into the SD shown on the right.

Fig. 16 Conversion rule on a parallel gateway

Crossover Service Requirements: Analysis and Design

93

Fig. 17 Conversion rule on the exclusive gateway

R6. For each exclusive gateway performed in the lane, we add an “alt” operator with a combined frame; the “alt” frame has the same operands as the outgoing flows of the exclusive gateway. Note that this will not be calculated when an outgoing flow contains only one end node. If the number of operands is one, we change the “alt” frame to an “opt” frame. In all cases, the outgoing message label is used to define the guard condition of each operand. As illustrated in Fig. 17, the BPMN exclusive gateway structure shown on the left of the figure is converted into the SD shown on the right.

3.3 Transformation from UML SDs to Microservice Design An SD shows the process of message invocation in a business flow. Software designers divide the whole system into multiple subsystems based on the SD [17] to shorten the development cycle and improve development quality. This section proposes three code rules for conversion from SDs into a microservice-based design solution. R7. Each actor in the SD is transferred to a subservice or submodule in the software system, and the actor is transferred to a module with the same name. R8. For each sending message in the SD, we add a service interface to the module corresponding to the message sender. The interface needs to provide the functionality corresponding to the semantic information of the message name. R9. For each return message in the SD, we add a service interface to the module corresponding to the message receiver. The interface needs to implement the functionality corresponding to the semantic information of the message name.

94

Y. Qiao et al.

3.4 Case Study In this section, a case study is illustrated to demonstrate the design-conversion process. As shown in Fig. 18, this example is a BP in the Meituan application, an e-commerce platform, which shows how a user places an order, a rider delivers products, and the user finally receives the expected product. In this case, convert the original BP diagram into an SD and obtain a microservicebased design solution by following the steps below. 1. For the swim lane in the picture, we apply R1 to convert the pool and lane into five participants: users, payment platforms, merchants, riders, and the Meituan system. 2. From the start node to the end node, we sort the messages in the converted SD according to the business order of the original BPMN, which helps ensure consistency between the sequence order in the SD and the original BP order. 3. For the gateways in the case, we apply R5 and R6 separately for transformation, which means that an exclusive gateway in the figure will be converted into an “alt” structure and a parallel gateway will be converted into a “par” structure. Then we can obtain the SD shown in Fig. 19. 4. We use microservice design-conversion rules, including R7–R9, to convert the SD into five microservice-based modules: a user module, payment module, merchant module, rider module, and Meituan system module. In each module, the functionalities provided by API interfaces are listed. Thus, we can obtain the microservice-based design solution described in Table 3.

Fig. 18 Ordering example of the Meituan application

Crossover Service Requirements: Analysis and Design

95

Fig. 19 Meituan ordering sequence diagram

4 Requirement-Evolution Analysis of Service Ecosystems According to the requirement-evolution scenarios of crossover service systems, population-based and community-based crossover convergence-evolution patterns are proposed from an ecological perspective. A value-driven crossover serviceevolution method is proposed considering the causal determinism and value-stream delivery in the evolution of crossover services, including population-based and community-based evolution methods. Software evolution is an essential topic in software engineering [18–22]. To increase understanding of stakeholder requirements’ trade-offs, Khatwani et al. [23] proposed integrating conflict-centric viewpoints for viewpoint merging and built automated tool support to build i* models. Guo et al. [24] suggested a microservice architecture-based interactive crossover service-fusion technique. Derguech et al. [25] described an approach for merging process models into a configurable process model based on annotations that takes a set of capability-annotated process models

96 Table 3 Microservice design

Y. Qiao et al. Module

Functionalities provided by API interfaces

User

Preorder Select an existing address Insert a new address Order Payment Confirmation Evaluation

Payment company Third-party payment Shop

Respond to an order

Rider

Take an order Check an itinerary Check an order

System

Access a user address Insert a new user address Place an order for a user Take an order from a shop Take an order for a rider Inquire about a rider’s itinerary information Query an order message from a rider Confirm receipt by a user

as input and returns a capability-annotated configurable model. Bouzidi et al. [26] proposed an integrated metamodel that includes all BPMN and use-case components, as well as new ones, to map traceable elements and match the business world represented by BPMN and the software-requirement world represented by UML usecase models. However, these approaches are solely concerned with model-merging procedures, not evolution of their models. Given the importance of crossover convergence in the growth of crossover services, rapidly evolving the original model into a new model has emerged as a significant research challenge in this field. This section focuses on the requirement-evolution patterns and approaches of crossover service ecosystems.

4.1 Evolution Patterns of Service Convergence Given the characteristics of crossover service ecosystems, we adopt an ecologyoriented evolution-analysis method based on the evolution patterns of crossover services from the perspective of the iteration relationship and driven flow of the value,

Crossover Service Requirements: Analysis and Design

97

Fig. 20 Requirement-evolution analysis for crossover services

goal, and service models in the service ecosystem. The main synergistic influenceanalysis framework is depicted in Fig. 20. The complicated connection between the role and value networks has pushed the creation of requirements, including goal models, process models, service models, and their coevolution. Two common evolution patterns of crossover services, namely, population-based and community-based crossover convergence-evolution patterns, are outlined via an in-depth investigation of typical crossover service scenarios from the perspective of ecosystems. In general, the population-based crossover convergence-evolution pattern is characterized as follows: a subject domain’s core service is evolved into a new variation to fulfill the requirements of a new domain, while the new variant service still belongs to the same domain. For example, to meet the business requirements of diverse domains, the insurance company extends its coverage options to include new flight-cancellation insurance and visa insurance according to the needs of various business domains. The derived insurance services are variations on traditional insurance services for diverse domains.

98

Y. Qiao et al.

A community-based crossover convergence-evolution pattern is defined as a pattern in which the core service of a subject domain integrates services from other domains to increase its own capability. For example, the core service of the Fliggy platform is a flight-booking service. This service is expanded to integrate services from other domains, e.g., accommodation, tourism, and insurance.

4.2 Ecological Evolution Analysis of Service Convergence To better describe the proposed approach, several definitions are provided. Definition 16 Submodel fragment: SMF = {E, R, SR, SD}, where E denotes the set of the model elements (i.e., value goal in value model, functional goal in goal model) in SMF, and R is the relations among the model elements. SR is the role that the submodel fragment subordinates, and SD is the domain that the submodel fragment subordinates. We can segment the value model, goal model, and process model into subvalue model fragments (SVMFs), subgoal model fragments (SGMFs), and subprocess model fragments (SPMFs), respectively. Definition 17 Evolutionary value goal: An evolutionary value goal is the value goal in the post-evolution value model, but not the value goal in the pre-evolution value model. Definition 18 Evolutionary subject and object roles: The subordinate role of an evolutionary value goal can be seen as an evolutionary role. Suppose the objective of an evolution process is for role a to expand role b’s business into its own business system. In that case, a is the evolutionary subject role and b is the evolutionary object role. When role a extends its business to other new domains, a is both an evolutionary subject and an object role. Definition 19 Evolutionary subject and object domains: A subordinate domain of the evolutionary value goal is considered an evolutionary domain. We call the domain that generates evolutionary value goals an evolutionary subject domain and that with potential solutions to satisfy those goals an evolutionary object domain. If the evolution takes place in the same domain, the domain is both an evolutionary subject and object domain. We present an ecology-oriented crossover service-evolution method based on crossover service-evolution patterns, as shown in Fig. 21. The solution we offer uses model fragments from multiple fields as domain model repositories to accelerate the evolution of the crossover service confronting other domains. This approach is detailed below.

Crossover Service Requirements: Analysis and Design

99

Fig. 21 Framework of the ecology-oriented evolution-analysis method

A. Evolutionary Requirements Elicitation Driven by Value Models We first segment the pre-evolution and post-evolution value models with role granularity to obtain the role SVMFs, which we traverse to collect all of the role’s value goals. We then compare the role’s value goals in the pre-evolution and post-evolution value models to determine the evolutionary value goals. The evolutionary domains and roles can be recognized simply after the evolutionary value goals of the roles are obtained. B. Determine an Evolution Pattern for Goal-Model Evolution We can select an appropriate development pattern for crossover services according to the differences between the population-based and community-based patterns, as well as according to whether a new domain will arise to fulfill the value-creation collaboration. If the evolutionary object domain exists in the pre-evolution models, the population-based evolution pattern can be applied; otherwise, the communitybased evolution pattern can be used.

100

Y. Qiao et al.

C. Population-Based Crossover Convergence-Evolution Pattern We can obtain the post-evolution goal model using the process below if the evolutionary object role exists in the pre-evolution models. 1. Reconstruct Subgoal Model Fragments of the Evolutionary Role An evolutionary value goal is a goal to be realized after evolution. In other words, it should be realized by the goals in the post-evolution goal model. This step determines how the SGMFs of the evolutionary subject and object roles should be evolved together. First, we calculate the semantic similarity between each goal in the SGMF of the evolutionary subject role and the evolutionary value goal. If the similarity is less than a given threshold, the SGMF of the evolutionary subject role is assumed to have no goals comparable with the evolutionary value goal. The evolutionary value goal is then added to the SGMF of the evolutionary subject role as a new root goal. Otherwise, we select the goal that most closely resembles the candidate subject’s evolutionary goal (CSEG). Then, using the hypernym, hyponym, and apposition relationships between nouns in the goal phrase, we determine the relationship between the evolutionary value goal and the CSEG. We use WordNet1 to judge the similarity relationship between goals. If noun A is a hypernym of noun B, the goal containing noun A is considered the parent goal that contains noun B; if noun A is a hyponym of noun B, the goal containing noun A is viewed as a subgoal of that contains noun B; and if noun A is an apposition of noun B, the goal containing noun A is viewed as a sibling goal of that contains noun B. If the evolutionary value goal is the CSEG’s child goal, then it should be added to the SGMF of the subject role as a child goal of the CSEG. If the CSEG is a child goal of the evolutionary value goal, the evolutionary value goal should be added to the SGMF of the subject role as the CSEG’s parent goal. If the evolutionary value goal is the CSEG’s sibling goal, the adjacent hypernym phrase is designated as their parent goal as well as the parent of the CSEG’s original parent goal. The SGMF of the evolutionary subject role after reconstruction is defined as a candidate SGMF of the evolutionary subject role. We first find the goals’ word vectors and use the cosine similarity to calculate their semantic similarity. Each goal in the goal model can be represented as a “verb + noun” phrase; therefore, we tokenize the phrase and compute the semantic similarity of its verbs and nouns. As indicated in Eq. 6, the semantic similarity of the goals is determined by a weighted sum of the semantic similarities of their verbs and nouns. GoalSim(Goal 1 , Goal 2 ) = α1 · Cosine(Goal 1 .verb, Goal 2 .verb) + α2 · Cosine(Goal 1 .noun, Goal 2 .noun),

(6)

where α1 and α2 are the weights of each part and α1 + α2 = 1. Because the verbs in a goal have little effect on the semantic representations of the goal, the similarity 1

https://wordnet.princeton.edu/.

Crossover Service Requirements: Analysis and Design

101

weight of nouns α2 should be higher than that of verbs α1 . If the similarity of the two phrases exceeds a certain threshold (e.g., 0.5), the goals are considered similar. 2. Model Fragment-Convergence Strategy We use the semantic similarity to search the SGMF of the evolutionary object role in the domain goal-model repository for a goal similar to the evolutionary value goal, which we consider to be the candidate object evolutionary goal (COEG). The SGMF comprises the COEG, and its subgoals are defined as the candidate SGMF of the evolutionary object role. Then, the evolutionary value goal is replaced with the COEG, and the SGMF of the evolutionary object role is added to the candidate SGMF of the evolutionary subject role. After convergence, we define the SGMF of the evolutionary subject role as the converged SGMF. 3. Dependency Update Strategy We determine the depender, depender element, resource (dependum), dependee, and dependee element set, collectively called dependency sets, based on the dependencies among roles in the pre-evolution goal model and add related dependencies to the converged SGMF to obtain the post-evolution goal model. The strategies for introducing dependents are described below. The dependencies of the converged SGMF are first obtained from the pre-evolution goal model. If a goal related to a role in the pre-evolution goal model fragment can only be accomplished by relying on the dependums of other roles, the role is considered a depender role, and the other roles serve as its dependee roles. Then, the SGMFs of the depender roles in the pre-evolutionary goal model can be obtained. When the evolutionary subject role has an evolutionary value goal, its depender role should add a new goal to fulfill the same requirement. The added goal is the depender role’s evolutionary value goal. To retrieve the SGMF of the depender role for the postevolution goal model, we append the depender evolutionary value goal to the SGMF of the depender role. Finally, the post-evolution goal model is created by combining the dependencies of the converged SGMF and the SGMFs of the depender roles in the pre-evolution goal model. If the evolutionary object role is a new role for the pre-evolution model, we can obtain the post-evolution goal model by (1) adding the evolutionary object role and evolutionary value goal to the pre-evolution goal model as a candidate evolutionary SGMF of the object role, (2) reconstructing the SGMF of the subject role based on the evolutionary value goal to obtain the candidate SGMF of the evolutionary subject role, (3) converging the candidate evolutionary SGMFs of the subject and object roles, and (4) updating the dependencies according to the dependency rules. These steps are similar to those listed previously. D. Community-Based Crossover Convergence-Evolution Pattern If the evolutionary object role exists in pre-evolution models, we can construct the post-evolution goal model by (1) adding the evolutionary value goal to the SGMF

102

Y. Qiao et al.

of the evolutionary subject role as a root goal and then reconstructing it to find the candidate SGMF of the evolutionary subject role, (2) obtaining the candidate SGMF of the evolutionary object role and converging it with the SGMF of the evolutionary subject role, and finally (3) updating the dependencies. However, if it is a new role in pre-evolution models, the post-evolution goal model can be obtained by (1) constructing the SGMF of the evolutionary object role from the evolutionary value goal as a root goal and candidate SGMF of the evolutionary object role, (2) converging the candidate SGMF of the evolutionary object role into the pre-evolution goal model, and finally (3) updating the dependencies. E. Process Model Evolution Based on Post-evolution Goal Model The mapping between goal and process models can be used to create the postevolution process model. 1. Obtain Candidate Evolutionary Process Model Fragments First, we search the domain process-model repository to find suitable SPMFs that can fulfill each goal in the converged SGMF and mark them as candidate SPMFs of the evolutionary object role based on the post-evolution goal model. Each SPMF in the domain process-model repository may accomplish a specified goal, and each process model fragment will be attached to a goal label that it can achieve. We calculate the semantic similarity between the SPMF and evolutionary value goal based on the SPMF’s goal label and consider the SPMF that exceeds a certain threshold to realize the evolutionary value goal. This SPMF is called the candidate SPMF of the evolutionary object role. The similarity calculation is the same as before. 2. Convergence Pre-evolution Process Model with Candidate Evolutionary Process Model Fragments First, based on the relationship between the evolutionary value goal and the other goals in the post-evolution goal model, we identify the process-execution sequence by following the relevant goal-execution sequence. The candidate SPMF of the evolutionary object role is then added to the SPMF of the evolutionary subject role in the appropriate position according to the process-execution sequence to obtain the post-evolution process model.

4.3 Case Study As discussed previously, Fliggy offers tickets, hotels, visas, car rentals, and other services. However, when customers utilize Fliggy’s reservation services for travel, they risk being unable to place or use their orders on time, resulting in annoyance or financial losses. As a result, the Fliggy platform has integrated some insurance

Crossover Service Requirements: Analysis and Design

103

booking services into their core business to provide customers with potentially valuable insurance services, such as flight delay insurance. In other words, the preevolution Fliggy platform ecosystem has undergone additional evolution toward the insurance business domain, among others, to provide value-added services. This type of evolution is viewed as a typical population-based evolution pattern. The value model of the Fliggy ecosystem without aviation insurance services is a pre-evolution value model, as shown in Fig. 22. In contrast, that with aviation insurance services added is a post-evolution value model, as shown in Fig. 23. The pre-evolution goal model is shown in Fig. 24. We can quickly obtain the insurance companies’ evolutionary value goal of “add aviation insurance” via the evolution method by comparing the pre-evolution and post-evolution value models. The goal still belongs to the insurance domain. As a result, the evolution process of the population-based evolution pattern can be leveraged. In this way, we can obtain the SGMF of the evolutionary subject role “insurance companies” and the CSEG “insurance coverage management.” The CSEG “insurance coverage management” is judged to be a child goal of the evolutionary value goal “add aviation insurance.” Therefore, as illustrated in

Fig. 22 Pre-evolution value model

104

Y. Qiao et al.

Fig. 23 Post-evolution value model

Fig. 25, “add aviation insurance” is added as a child goal of “insurance coverage management” to the SGMF of “insurance companies.” In the domain goal-model repository, we can search for the evolutionary value goal “add aviation insurance” and find the most similar goal of “provide aviation insurance.” Then, we mark this goal and its child goals, “provide flight cancellation insurance” and “provide flight delay insurance,” as the candidate SGMF of the evolutionary object role. Finally, we replace the goal “add aviation insurance” with the candidate SGMF of evolutionary object role using the model fragment-convergence strategy in the pre-evolution goal model. Finally, we update the appropriate dependencies among roles and goals according to the dependency strategy to obtain the post-evolution goal model, as illustrated in Fig. 26.

Crossover Service Requirements: Analysis and Design

105

Fig. 24 Pre-evolution goal model

5 Summary This chapter first proposes a metamodel for crossover service requirements modeling. Then, a requirement-modeling approach is presented based on the proposed metamodel. Next, because convergence is a typical characteristic of the crossover service, a convergence-analysis approach to crossover service requirements is proposed from the perspective of goals and processes. A service-design approach is then proposed to help design analysts construct microservice interfaces based on the converged process. Finally, an ecologically-oriented evolution method for crossover service ecosystems is introduced in detail, where two evolution patterns, population- and community-based service convergence-evolution patterns, are summarized.

106

Fig. 25 Reconstruction of SGMF of the evolutionary subject role

Fig. 26 Post-evolution goal model

Y. Qiao et al.

Crossover Service Requirements: Analysis and Design

107

References 1. Liu Z, Li B, Wang J, Qiao Y (2020) A value-driven modeling approach for crossover services. Int J Web Serv Res 17(3):20–38 2. Thew S, Sutcliffe A (2018) Value-based requirements engineering: method and experience. Requir Eng 23(4):443–464 3. Zarvic N, Daneva M, Wieringa R (2007) Value-based requirements engineering for value webs. In: International working conference on requirements engineering: foundation for software quality, pp 116–128 4. Akkermans JM, Gordijn J (2003) Value-based requirements engineering: exploring innovative e-commerce ideas. Requir Eng 8(2):114–134 5. Caetano A et al (2017) Representation and analysis of enterprise models with semantic techniques: an application to ArchiMate, e3value and business model canvas. Knowl Inf Syst 50(1):315–346 6. Asadi M, Gröner G, Mohabbati B, Gaševi´c D (2016) Goal-oriented modeling and verification of feature-oriented product lines. Softw Syst Model 15(1):257–279 7. Engelsmana W, Quartelc D, Jonkersa H, van Sinderen M (2011) Extending enterprise architecture modelling with business goals and requirements. Enterp Inf Syst 5(1):9–36 8. Liu Z, Li B, Wang J, Qiao Y (2020) A value-driven modeling approach for crossover services. Int J Web Serv Res (IJWSR) 17(3):20–38 9. Peng Y, Li B, Wang J, Liu Z (2020) An approach of crossover service goal convergence and conflicts resolution. In: IEEE World Congress on services (SERVICES), pp 225–230 10. Shan Y, Qiao Y, Li B, Wang J (2020) A process convergence approach for crossover services based on message flow partition and merging. In: IEEE International conference on services computing (SCC), pp 178–185 11. Zemni MA, Mammar A, Ben Hadj-Alouane N (2016) An automated approach for merging business process fragments. Comput Ind 82:104–118 12. Ozkaya M, Erata F (2020) A survey on the practical use of UML for different software architecture viewpoints. Inf Softw Technol 121(4):106–275 13. Rivera L, Villegas N, Tamura G et al (2018) UML-driven automated software deployment. In: Proceedings of the 28th annual international conference on computer science and software engineering, pp 257–268 14. Lam B, Nguyen V, Phan C (2020) An approach for application generation based on BPMN. In: International conference on knowledge and systems engineering (KSE), pp 115–119 15. Nepomuceno T, Oliveira E Jr (2021) Software product line traceability and product configuration in class and sequence diagrams: an empirical study. In: International conference on enterprise information systems, pp 97–204 16. Bouzidi A, Haddar N, Ben-Abdallah M et al (2020) From BPMN to sequence diagrams: transformation and traceability. In: Proceedings of the 15th international conference on evaluation of novel approaches to software engineering, pp 438–445 17. Al-Fedaghi S (2021) UML sequence diagram: an alternative model. arXiv:2105.15152 18. Decan A, Mens T, Grosjean P (2019) An empirical comparison of dependency network evolution in seven software packaging ecosystems. Empir Softw Eng 24(1):381–416 19. Mens T, Claes M, Grosjean P, Serebrenik A (2014) Studying evolving software ecosystems based on ecological models. Evolv Softw Syst 297–326 20. Khelladi DE, Combemale B, Acher M et al (2020) On the power of abstraction: a model-driven co-evolution approach of software code. In: Proceedings of the ACM/IEEE 42nd international conference on software engineering: new ideas and emerging results (ICSE-NIER), pp 85–88 21. Qi Q, Cao J, Liu Y (2020) The evolution of software ecosystem in GitHub. J Comput Res Dev 57(3):513–524 22. Teixeira J, Hyrynsalmi S (2017) How do software ecosystems co-evolve. In: International conference of software business (ICSOB), pp 115–130 23. Khatwani C, Jin X, Niu N et al (2017) Advancing viewpoint merging in requirements engineering: a theoretical replication and explanatory study. Requir Eng 22(3):317–338

108

Y. Qiao et al.

24. Guo S, Xu C, Chen S, Xue X, Feng Z, Chen S (2019) Crossover service fusion approach based on microservice architecture. In: IEEE International conference on web services (ICWS), pp 237–241 25. Derguech W, Bhiri S, Curry E (2017) Designing business capability-aware configurable process models. Inf Syst 72:77–94 26. Bouzidi A, Haddar N, Ben Abdallah M, Haddar K (2018) Alignment of business processes and requirements through model integration. In: 2018 IEEE/ACS 15th International conference on computer systems and applications (AICCSA), pp 1–8

Crossover Service Infrastructure: Service Network Shengye Pang, Bangpeng Zheng, Jianwei Yin, and Shuiguang Deng

Abstract Although enterprises in the crossover service ecosystem open their own internal services, they also need to invoke open services from the other service participants to collaborate and complete the complex BP. The collaboration of services between crossover businesses requires microservices to invoke each other. The myriad microservices, which are distributed across multiple organizations, form a heterogeneous, complex, and distributed service-invocation and -operation network, which we call a service network. Crossover service collaboration must shield this heterogeneous environment and provide a virtual transparent and virtual unified convergence environment for service governance. Keywords Crossover service network · Service switch · Service router · Service access · Network management Similar to search engines Google and Baidu, which collect information from the Internet and provide information-retrieval services to users after processing, a service network accesses open services in the crossover service ecosystem for users or enterprises to retrieve and invoke, thus realizing service interconnection and crossover collaboration. Recently, a number of centralized service registries have emerged to address the registration and discovery of services. For example, ProgrammableWeb.com,1 which is the largest online RESTful service repository (APIs and mashups), collects over 24,000 APIs and 8000 mashups in than 400 1

https://www.programmableweb.com/.

S. Pang (B) · B. Zheng · J. Yin · S. Deng Zhejiang University, Hangzhou, China e-mail: [email protected] B. Zheng e-mail: [email protected] J. Yin e-mail: [email protected] S. Deng e-mail: [email protected] © Zhejiang University Press 2023 J. Yin et al. (eds.), Convergence in Crossover Service, Advanced Topics in Science and Technology in China 68, https://doi.org/10.1007/978-981-19-8844-8_4

109

110

S. Pang et al.

diverse categories online. However, as the number of services grows, the centralized service registry shows limitations in disaster-tolerant processing, load balancing, and scalability. Unlike traditional computer networks, the service network, as an overlay network, is also a new application network. Currently, there is no relevant model to support the construction and governance of this kind of network using existing computer network theory and infrastructure. This chapter proposes a service network infrastructure that can realize fast, secure, and efficient access for open services; realize routing, finding, and dynamic adaptation; and efficiently support the construction, governance, and evolution of large-scale service networks.

1 Service Network The open business model has grown rapidly with the development of the Internet. Organizations across all industries have already moved businesses onto the Web, which has brought about a fast growth of various web services. Most such services are isolated, but services from a single field cannot meet the complex requirements of users [1]. The crossover service is proposed to create value that a single-domain service cannot provide, thus achieving a value-emergence effect exceeding the sum of its parts [2]. However, inconsistencies among businesses and their interfaces complicates the interconnection of services in crossover convergence. Fully achieving the potential of crossover services requires a sound framework to efficiently deploy, publish, discover, compose, monitor, and optimize access to services in the crossover service system. Thus, a new service infrastructure, the service network, is proposed to solve the above problems. To deploy and manage crossover services, an approach combining hardware with software is designed that operates on two novel service devices: the service switch and service router.

1.1 Service Network Model Service-oriented architecture (SOA) is a style of software design where services are provided through a communication protocol to the other components over a network by application components. The aim of the SOA model is to allow developers or end users to dynamically discover and assemble software modules to fulfill their needs. One of the stumbling blocks toward this goal is the difficulty for potential users to efficiently search for and retrieve services, particularly when those services are independently deployed by a large set of providers on open, large-scale networks. As shown in Fig. 1, the example e-commerce platform consists of three layers: entity, service, and platform. The first layer contains all the entities providing various services. In e-commerce, the entity layer is mainly composed of payment companies,

Crossover Service Infrastructure: Service Network

111

Fig. 1 Service integration in e-commerce

delivery companies, and sellers. The second layer contains all the services provided by the entities, which are each able to fulfill a task in a particular field or enterprise. However, these services from different companies usually have different formats. The third layer, the platform, collects all the services and arranges these services according to its BPs to meet the needs of users. As shown in Fig. 1, there are several challenges. (a) Environmental heterogeneity. There are a large number of services from different platforms with different languages and communication styles, which leads to trouble during deployment. (b) Separate distribution. Services are widely distributed across different providers and their integration is complex. (c) Service heterogeneity. There are several services which have the same or similar functions but different operations, making it difficult for consumers to find the most suitable service. To address the above challenges, a network infrastructure named service network (ServNet) is expected to promote service management and delivery [3]. In the crossover service system, services are connected each other to produce the service network. As an overlay network, ServNet plays a role of broker in the SOA solution based on the traditional network. Service interoperation becomes more difficult with the increase in services. Just as the need to find information expedited the birth of search engines, such as Google and Baidu, ServNet provides an infrastructure to carry out service interoperation and crossover cooperation in an open and dynamic network environment. As shown in Fig. 2, the conceptual architecture of ServNet consists of two layers: the service layer and the network layer. The service layer contains all the services provided by the participants through service switches, each

112

S. Pang et al.

Fig. 2 Conceptual architecture of ServNet © [2022] IEEE. Reprinted, with permission, from Ref. [5298620497793]

of which has the ability to perform a task in a particular field or enterprise, such as payment services, logistics services, and order services in the e-commerce scenario. The network layer consists of router nodes distributed in different geographical areas. The service layer can be connected to the network layer through the service switch to realize data forwarding of service-discovery requests and service invocations. The service-network interconnection (SNI) model is a conceptual model that describes the universal standard for the communication functions of a service network regardless of the service’s underlying internal technology and specific protocol suites. Therefore, the objective is the interoperability of all diverse services containing standard communication protocols through the encapsulation and de-encapsulation of services for all networked communication. As shown in Fig. 3, the SNI model consists of four layers. The physical layer provides a method to share and transport data from one node of the network to another, serving as a traditional network. The exchange layer in the protocol stack, based on REST, is responsible for describing a specific service using Crossover Service Description Language, thus providing the common communication method among different service nodes (e.g., CS-routing). The service layer is responsible for providing easy deployment/management functionality, such as service network management framework, quality of crossover service (QoCS), and crossover service-level agreement. The application layer is responsible for service integration. To provide good value, standardized service (StanS) is designed to provide a transparent logic view for heterogeneous services. Formally, ServNet is defined as an 8-tuple: ServNet = , where Ns , Nr , S, St , Rwr , Rws , Rss , and Rst are respectively the service switch node, service router node, actual service, StanS, relation between the service

Crossover Service Infrastructure: Service Network

113

Fig. 3 Protocol stack of ServNet

switch node and service router node, relation between the service switch node and actual service, relation between actual services, and relation between StanS and the actual service. The two service nodes can be defined as Nw = and Nr = . NP (Node Property) is the basic information of the node, including its name, description, and address. SL (Service List) is the repository that stores all the local service information, and RT (Routing Table) is the routing information records of nearby router nodes. As shown in Fig. 2, there are several service routers and service switches distributed across different provinces in China for the e-commerce scenario, such as Nr1 = , Nr2 = , Nw1 = . The key element of ServNet is service. In this model, a service is defined as a 4tuple: S = , where SP (Service Property) is the basic information of the service, SI (Service Interface) is the operation information of the service, QoS is quality of service, and SC (Service Category) stores the category and classification information, which contains the semantic features of the service. As shown in Fig. 2, there are several payment services open to the service network from the e-commerce scenario, such as Salipay = , Sweixinpay = . StanS is the abstract service in functionality and is defined as a 3-tuple: St = . Rst is the relation between StanS and actual service, which is described later in this book. For example, the standardized payment service from the e-commerce scenario, Stpay = has the relations and between this service and the payment services. Specially, in relation Rwr , each service switch node can have one and only one service router node as the parent node. Rws can help locate an actual service from

114

S. Pang et al.

the corresponding service switch node. Generally, each service switch node represents an enterprise within the network. Rss is the service relation, which is the logical relationship among actual services, such as callback, sequence cooperation, and asynchronous messaging. These complex processes require the cooperation of services.

1.2 Architecture ServNet is a service-based network that enables sharing services and is composed of service switches and routers. As shown in Fig. 4, ServNet includes a service access network and service backbone network. The service access network connects organizations to the backbone network through service switches, and the service backbone network carries the heaviest traffic and connects multiple access networks through service routers. A service switch is an access point that acts as a proxy for multiple services within a company at the service access network. For most enterprises, it is difficult to

Fig. 4 Architecture of the service network

Crossover Service Infrastructure: Service Network

115

open their own services efficiently and safely, and the service switch is designed as the entrance to the network to realize service publishing, access control, and service management. Enterprises can access the ServNet and publish services through service switches. Moreover, they can search and apply for other services for ease of use from different companies throughout the network. The service switch handles the service requests from the network and service responses from multiple service providers. As shown in Fig. 5, the framework of the service switch consists of the following four layers: infrastructure (cabinet, mains, panel, etc., which are the basis of the switch), device (computing server and storage server, which are the core hardware of the switch), network (virtual service router and virtual firewall, which are responsible for network management and safety control), and application (authentication, publishing, management, etc., which are the main functions for the service network). A service router is a routing point that transfers services within the service backbone network. The service router forwards service requests between service nodes to realize service discovery, caching, and routing. Moreover, the service router stores the routing information of the service network and can adjust the network scale, peer status, and connections among peers. As shown in Fig. 5, the framework of the service router also consists of four layers. The infrastructure and device layers are the same as those of the service switch and are the core hardware of the router. The network layer provides reliable delivery of service information among different nodes, including message and routing. The virtual service router in this layer is responsible for network management. The application layer is responsible for service caching, routing, logging, etc., which are the main functions of a service network.

Fig. 5 Devices in the service network

116

S. Pang et al.

1.3 Core Devices ServNet is comprises two core devices, the service switch and router, which are detailed in this section. • Service Switch The service switch is the hardware that connects the enterprise on a service network to receive and forward data to and from internal and external services. A service switch is a service bridge that uses service addresses to forward services at the exchange layer. As illustrated in Fig. 6, there are several key functional modules. • The registry module (ReM) maintains the service information and business data of the enterprise. Once a service is registered successfully, it is stored locally and its metadata are broadcasted to the whole network by flooding or other methods. The service can be searched and used by other service switches shortly thereafter. • The adapter module (AdM) is designed to support environmental heterogeneity. AdM provides a variety of adaptors that can be implemented in different languages to enable communication with heterogeneous services. The SOAP WS, RESTful WS, and database adaptors translate data formats between services within the invocation process. As long as they are semantically compatible, the various services connected to different adaptors can be connected and integrated despite having different hardware and software platforms, languages, and APIs. • The policy module (PoM) uses several policies to improve performance. The proxy policy enables users to invoke services via the proxy. The load-balance policy of the service switch enables scalability and load balancing by increasing the number of processes. The service-caching policy enables some nodes to cache

Fig. 6 Architecture of service switch

Crossover Service Infrastructure: Service Network

117

the result of a service invocation, which can fully exploit the resources of edge nodes in the network. • The mapping module (MaM) enables users to invoke the service or receive the result in a particular format. An intuitive graphical interface is provided for users to generate rules files. • The authentication module (AuM) is designed based on key cryptography and using role-based access control policy to protect the data. • Service Router A service router is a networking device that forwards services within the service network. Service routers collect service information from service switches and broadcast the data in the whole network, as well as forward requests to the corresponding service nodes if services are invoked by users. As depicted in Fig. 7, the service router contains the routing, storage, processor, and StanS components. • The storage component (StC) consists of three parts: the service cache, which includes some service metadata and query results; the routing information, which is the basis of the whole network; and the structural information of the service network. • The routing component (RoC)’s function is to forward the service request based on the service ID, which is quite different from the IP address in the traditional network. • The processor component (PrC) provides a communication mechanism between internal and external resources. There are two types of messages: service messages

Fig. 7 Service router architecture

118

S. Pang et al.

and route messages. Once a message is received, it will be preprocessed by the PrC, then transmitted to the routing or storage component. • The StanS component (SsC) is designed for homogeneous services with similar functions in the service network. When any fault is discovered in a web service, the SsC can dynamically replace services with suitable ones, which greatly improves the availability and reliability of services.

1.4 Case Study As growth of the user base of traditional e-commerce has reached a bottleneck, major e-commerce companies are beginning to focus on the vast market of rural areas. However, the poor network coverage and limited logistics systems in rural areas, as well as farmers’ inability to apply the network, have limited the development of rural e-commerce. To solve these problems, we have developed an e-commerce platform based on a prototype crossover service network system, JTang Yggdrasil, to realize the sale of online goods to the countryside and agricultural products to the city. With JTang Yggdrasil applied as shown in Fig. 8, a service switch is provided to allow each participant to access the network. Once the service switch connected, the participants can publish their e-commerce-related services easily based on various adaptors, unified integration semantics, and environment-aware management mechanisms. The e-commerce platform can also apply for and provide these integrated services to customers. In addition, JTang Yggdrasil provides a rich user interface and advanced functionality to provide convenient operation, including a web page with statistical analysis, route policy configuration, and standardized services. In addition, JTang Yggdrasil has also been utilized in other areas with excellent performance. In the medical field, JTang Yggdrasil has been applied to more than thirty large-scale hospitals and two regional health institutions across ten provinces in China. For example, JTang Yggdrasil has been running successfully for the Children’s Hospital of the School of Medicine, Zhejiang University, for approximately a year, and its web services have been accessed hundreds of millions of times.

2 Service Wrapper and Access Many service providers provide their services and data through Web systems. However, most such systems operate in a closed and independent environment, making it difficult for software developers to use source data and services to fully unlock their effectiveness. Meanwhile, the network is also connected to a large number of IoT devices, and users and enterprises are concerned with the information collection, control of critical infrastructure, and perception of the real world provided by these devices, i.e., the services that the IoT can provide. Therefore, to achieve

Crossover Service Infrastructure: Service Network

119

Fig. 8 E-commerce with service network

crossover convergence among multiple participants, the first issue to be addressed is the packaging and access of services.

2.1 Web Service Wrapper Service providers tend to display their service data through web pages; however, various web pages restrict the use of these source data by developers. In the Rural Taobao crossover scenario, the business involves a number of fields, such as agriculture, logistics, and payment. Before the crossover collaboration, the respective businesses are not packaged in the form of services, but are executed as part of a whole system. In logistics companies, logistics information is usually saved in the local server, making it is difficult for the Rural Taobao platform to obtain detailed logistics information from outside. Thus, it cannot provide real-time logistics tracking for customers. To achieve crossover collaboration of multiple participants, the service needs to be opened. A service wrapper system is intended to package the data from web pages into a service and provides the RESTful API for invocation during the development process. We introduce the service wrapper system, which consists of two main components: the service extractor and service invoker. The former is responsible for handling dynamic web pages, block segmentation, and service information generation. The latter is used to invoke the services (call the corresponding APIs) generated by the service extractor. Finally, the service extractor can obtain data whose structure is predefined by the wrapper user. Figure 9 shows an overview of our system.

120

S. Pang et al.

Fig. 9 Overview of service wrapper system

(1) Service Extractor The service extractor is used for service generation. It receives a web page and encapsulates the internal specified information into a web service. There are two cases considered when extracting data from web pages: (A) Dynamic web pages. First, we need to find the fillable forms on the page and provide them to our users to decide which form to use. The user selects a form and enters some example values, which will be automatically inserted into the form by the system to obtain the final static web page. (B) Static web page. In this case, we can directly segment the page into blocks, sort the blocks based on their importance, analyze the data structure of each block and the meaning of each field, then send these blocks to our user to determine which blocks to encapsulate. In both cases, after modifying the service information slightly according to the user’s input, we obtain the web service generated by the extractor. (2) Service Invoker The service invoker receives an API request from the caller and returns structured data designed by the wrapper user. As shown in Fig. 9, after a user sends an API request with the GET method, the service invoker accesses the corresponding service information in the database and handles the request with its modules. The whole process of service generation and invocation is shown in Fig. 10. Our system is treated as a black box, and user operations on the front end are very simple. In the process of service generation, the dynamic form processor is used to detect and extract the information from fillable forms on a web page. A form usually contains several fields and a query button. For example, one query form on the Amazon website contains an input box and a search button, which are the field and the query button, respectively. The static page-segmentation module separates a given static web page into blocks using web page-segmentation methods. We find that many web pages are generated based on templates, so the developer simply needs to fill these templates with a list of data from the back-end database to create a page. The blocksorter module can organize the blocks based on their degree of importance and keep the top n (predefined value) blocks for users to choose. After sorting, the desired

Crossover Service Infrastructure: Service Network

121

Fig. 10 Process of service generation and invocation

block can be found quickly. Although web pages vary, we can find blocks containing common features, which are regarded as the main blocks. Next, we need to generate the extraction rules for our service invoker to extract data from these blocks with the extraction rule-generator module. The field meaning analyzer is used to generate an initial name for the final output field of the API. Each output field corresponds to one of the elements in the subblock. Last, the service information generator module is used to store the field information, text content, and other auxiliary data (such as the service name, description, or URL address) of the candidate blocks into another JSON file with similar data structures. During service invocation, the parametric analyzer is responsible for analyzing the request parameters. We classify the request parameters into three categories: system request parameters, application request parameters, and filter parameters. The service request processor (SRP) is used to manage the system request parameters. If an APIKEY is needed for the service, the SRP can check the validity of the key. Next, we handle the application request parameters in the service information parser module. Finally, the result filter helps the caller select items from the output of the last module. For example, if there is an output parameter called price in a service, we can use the key–value pair “price = 35” to find products in the set whose price is $35.

122

S. Pang et al.

2.2 IoT Service Access An important challenge for the development of the IoT is the growing number of connected devices. These devices and the information they generate are necessary resources in IoT solutions. However, their various interfaces, protocols, and data formats impede the manual connection of these resources to the IoT environment. The service-oriented IoT resource-access and -provisioning framework is an infrastructure that can access heterogeneous devices in a unified manner, collect sensor information, transmit control commands, and share resources with IoT’s application development environment [4]. It defines (i) a protocol stack for device connection and resource access using protocol self-adaptation; (ii) a description model for resource and entity modeling, decoupling of upper applications from underlying resources, and resource reuse; and (iii) a resource-provisioning layer for data interpretation and resource service mapping, which is implemented based on the resource access provided by the protocol stack and the resource–entity binding provided by the description model. Moreover, it utilizes a message queue based on the publish/subscribe model to share resources. Figure 11 shows the architecture of our proposed framework, which is composed of a unified resource access system, description model, resource-provisioning layer, and a publish/subscribe system, to achieve resource access, resource–entity modeling, data interpretation, service resource mapping, and resource sharing. Among them, the bottom layer is the abstraction of the perception layer, which provides large-scale heterogeneous sensing resources. Based on the resource-access and -provisioning framework, application developers in the IoT environment can implement business logic and functions based on services provided by the framework. (1) Resource access is the fundamental component of resources entering the IoT services. To solve the multisource heterogeneity of resources in the sensor network, we designed the resource-access module in the framework for the unified recognition and adaptive transmission of resources. The access module maintains connection and communication with the device by listening to different ports and establishes connections to heterogeneous devices through a protocol stack system with a dependency-inversion pattern, which loosely couples the framework so it can flexibly and dynamically adapt the heterogeneity of all resources. (2) Resource provisioning exposes resources, such as devices, to the IoT environment and maps resources into services to allow visitors to access resources in the form of interfaces. Based on the resource-access function, this module extracts device information from raw packets sent by the perception layer. This module also provides resource–entity binding for resource and service mapping, enabling users to operate on resources by simply manipulating entity attributes. Moreover, the platform interprets the raw sensing data into an easy-to-understand, machine-processible format based on the resource–entity binding.

Crossover Service Infrastructure: Service Network

123

Fig. 11 Architecture of service-oriented resource-access and -provisioning framework

(3) Description modeling uses resource- and entity-level modeling to describe the resource information semantically. The resource model defines the characteristics, properties, and access method of resources, while the entity model describes the properties, relationships, and contextual information of entities. Above the resource-provisioning layer, we use a publish/subscribe-based message queue to implement the sharing of resource services. Through a unified defined interface, users can subscribe to the services they need. • Unified Resource Access In the IoT, the underlying sensing resources are fragmented and heterogeneous. When applications acquire these resources, they must first interact with heterogeneous protocols [5]. To parse the message package, we need to automatically adapt the protocols contained in the message package and combine them sequentially. Thus, unified resource access is needed. The unified resource-access framework is shown in Fig. 12. The bottom of the framework is connected to the perception

124

S. Pang et al.

Fig. 12 Structure of unified resource access

layer, which can receive the transmitted sensing resources. At the top is a unified interface layer connected to the resource-provisioning layer, which is responsible for publishing and sharing access resources. Through this layer, sensor devices and nodes can be connected to the network through a gateway, or devices with networking capabilities can be connected directly to the network. The unified resource-access framework takes the protocol stack as its core to realize unified access to heterogeneous devices through self-adaptation of protocols. The protocol stack consists of a series of protocol components and stacks for packet parsing. The protocol is user operable and is applied to parse messages sent by the perception layer. The protocol can be deployed on the platform and managed in the form of OSGi components. The protocol stack can combine different protocols to achieve layer-by-layer parsing of data packets. Meanwhile, the protocol assembly for protocol stack can be achieved manually or through self-adaptation.

Crossover Service Infrastructure: Service Network

125

• Resource Provisioning After the resource is connected to the platform, the content presented is not acceptable to the machine and user. Resource provisioning further parses resources into wellunderstood and machine-processible formats, combine context scenarios to give them specific semantics, and present them to users in the form of services. Resource provisioning consists of resource publishing, data dissemination, a message queue based on publishing and subscribing, and an interface layer adapted to various services, as shown in Fig. 13. Resource access aims to obtain resource information from the received message package and publish the resource description to the platform, while resource provisioning integrates and publishes resources. Resource integration includes resource–entity-binding and resource service-mapping operations. After resources are accessed, the platform selects suitable resources and provides them to users according to the resource requirements submitted by application developers. Meanwhile, the platform binds resources to entity attributes, as shown in Fig. 14. Then, the platform can not only interpret the raw perception data into different scene information according to different entity fields but also map the related operations of entity attributes to operations directly on resources. Application developers only care about the entities in the application scenario, so they need to map the user’s operations (Get/Put) on entity attributes into resource-sensing and -control services via resource-service mapping. Service mapping aims to map operations on resources onto RESTful service interfaces. Application developers can obtain services for resource operations by binding access interfaces and resource entities. Resource publishing is the publication of resources to the message queue based on the publish–subscribe model through the data interface. Meanwhile, application developers subscribe to topics of interest from the message queue. This is an asynchronous call method for resource services. The message queue is composed of many nodes, which are called message brokers and can each manage many topics. Each topic is physically divided into multiple partitions based on its size. The message broker also provides message-publication, -subscription, -notification, and -routing functions.

3 Service Network Management In the crossover service network, the geographical distribution generates a natural service distribution, and many services are stored in the network in a scattered manner. The complex invocations generated among these services in different locations creates huge performance challenges for the whole service network, necessitating improvements in the efficiency of service routing and caching, optimization of the service-deployment strategy, and the realization of dynamic service adaptation to support reliable operations of the entire cross-border service network.

126

S. Pang et al.

Fig. 13 Structure of resource provisioning

3.1 Service Routing A variety of approaches have been proposed to provide transitional service discovery, ranging from distributed architectures to mitigate the centralization of service registers [6] to Semantic Web technologies to provide more effective descriptions and matchmaking techniques [7, 8]. However, these methods are not appropriate for the proposed service network, as there are numerous open services in the service network. The complex relationships among these services result in frequent service invocations, which, combined with the limited resources of the network, lead to inefficient communication. Thus, an efficient service-routing algorithm is needed to support the efficient operation of the service network.

Crossover Service Infrastructure: Service Network

127

Fig. 14 Resource–entity binding

The routing algorithm includes the following main tasks: (1) routing path initialization to construct the routing path in the RTs when two service nodes communicate for the first time; (2) adaptive path updating to dynamically adjust the route when network fluctuations cause link delays; (3) path-fault detection to enable the routing path to be reconstructed adaptively when a node on the routing path fails; and (4) multiservice routing to determine how to route the request when multiple service nodes are available. (1) Routing Path Initialization When a node communicates with the target node for the first time, the routing path needs to be established between them. Assume that during communication, the service switch node can access the other directly within the same area, but the service router node is needed when the two nodes are located in different areas. When a routing path is established between two services nodes, the source node sends a message to several nodes in the local area, which in turn forward the message to their neighbors with certain probability after receiving the request until the destination node is found. The probability of the message being forwarded by the router node in the area is 1. For other nodes, the forwarding probability depends on the node status and is inversely proportional with its current load. Figure 15 shows an example of path initialization between source node (R1, S2) and target node (R2, S9). As node (R1, S2) is not connected directly to regional router node R1, it needs to communicate across regions by forwarding the message to node (R1, S9) or node (R1, S3).

128

S. Pang et al.

Fig. 15 Path initialization

After the routing path established, the target node needs to update its local routing table and temporarily record the information of the relay nodes, such as the IP, port, and cost. If these records are inconsistent, another optimal path needs to be selected. (2) Adaptive Path Update After routing path initialization, an optimal path is selected. Meanwhile, several other candidate paths are saved for the path-initialization process. The selected path is updated if the connection is lost. As shown in Fig. 16, the initial routing path is (R1, S2) → (R1, S9) → R1 → R2 → (R2, S6) → (R2, S9).

Fig. 16 Routing path update

Crossover Service Infrastructure: Service Network

129

Assume that the original path is invalid because of the connection between node (R1, S2) and node (R1, S9) lost. Based on the overhead of reconstructing the routing path, the mechanism to adaptively update the routing path is designed to maintain the highly efficient operation of the service network. The nearest node (R1, S3) is chosen added to the path, which retains the initialized path to the target node (R2, S9). In this process, every service node in the path continuously updates the link cost via step-by-step feedback. The cost is inexpensive, as the predecessor node only needs to receive the subsequent node’s updated message. (3) Path-Fault Detection Let R = denote the routing path from source node Pi to target node Pj . Node Pi sends a Ping command to the node Pj periodically with a random number N to guarantee the uniqueness of the command. Thus, the encrypted information of routing path R is Key1 (N, IP2 , Key2 (IP3 , Key3 (…))). To evaluate the number of hops on the routing path, we attach N + 1 to the Ping command each cycle and attach N − 1 to the Pong command while returning. When the target node receives an error message, there are two possible situations. The first is that the packet is lost completely due to network error. In this case, the source node fails to receive the return information from the target node and cannot to locate the fault node within the routing path. The original routing path is judged to be unavailable if the failure still occurs after two retries, at which time the source node can initiate a new routing path to the target node. The second situation is that an error occurs on a relay node, resulting in an incorrect return value. According to the initial number from node Pi and return value from Pj , the error node in the path can be detected easily. In this case, dynamic adjustments to the service node preceding the error node on the routing path are needed (Fig. 17). (4) Multiservice Routing There are several services with the same or similar functions in service network, which complicate the process of service routing. When there are multiple service nodes available, two situations arise: service nodes with similar service functions are either distributed in the same area or in different areas. In the first case, as shown in Fig. 18, the target service node is replaced with the corresponding service router node, and the service directory of the router node is adjusted. The source node maintains the routing path to the router node for this area, while the service router node maintains the policy to the final target nodes with similar service functions. For services nodes distributed in the different areas, it is necessary to choose the optimal routing path to the service router nodes in multiple areas when the service-routing path is first established. A set of alternative routing paths to the other service nodes is maintained.

130

S. Pang et al.

Fig. 17 Path-fault detection

Fig. 18 Service distributed in the same area

3.2 Service Caching Caching on network is a universal technique that can reduce both access latency and backend load [9]. There are several existing studies on service caching and placement [10, 11], but all of these strategies are fundamentally limited because they rely on the assumption that the service can be cached or offloaded to network nodes. Service caching in the service network faces two main challenges. First, most services open to

Crossover Service Infrastructure: Service Network

131

Fig. 19 Caching architecture for service network

the Internet are RESTful services, which run entirely within the enterprises of service providers (e.g., electronic healthcare record services run within hospitals). Users can call these services and retrieve data via different proxies, but the data originate from the service providers. These services cannot be cached entirely to proxy nodes. Second, most studies on caching policies focus on a single node; however, a service network is a multilayer network. Hence, when designing caching policies and cache-management strategies for service networks, it is not only necessary to maximize the hit rates of individual nodes, but also important to fully utilize the node resources of the entire service network. To address the above challenges, a flexible mechanism is needed to determine the appropriate caching method for the service network. A caching architecture for a service network is shown in Fig. 19. The main tasks of the caching mechanism are cache space division, service replacement, multilayer caching, and collaborative caching. Cache space division. The service-invocation information cached in service nodes can be divided based on several behaviors. (1) Resident information. In this case, the node allocates a larger cache tolerance and default cache time to identify information that is popular and has been requested frequently within a period of time. The area where the resident information cached is called the stable area. (2) Change information. In this case, the target service-invocation information changes frequently. The node allocates a smaller cache tolerance and default cache time, and the caching location is called the change area. (3) Recycle information. The service-invocation information cached in the recycle area has a low hit rate and is rarely requested. For this type of information, the node allocates the smallest cache tolerance and default cache time. These three types of cache information can be converted to each other. The change information can be converted into resident information by reaching a threshold value

132

S. Pang et al.

of request frequency and into recycle information when the service-invocation information frequency decreases to below another threshold value. The resident information can be converted into change information when requests for its serviceinvocation information decrease in frequency. Similarly, the recycle information can be converted into change information because of frequent requests for the serviceinvocation information. It is important to note that the service-invocation information is categorized as change information when it is first cached into the node. Service replacement. This task is performed as follows: (1) When the service request is received, continue to step 2 if the cache at least partially hits; otherwise, proceed to step 6. (2) Update the cache value of the hit service-invocation information as V=

n ⅀

Si ze(i ) × (Fr (i )/(Tnow − Tscor e )),

(1)

i=1

where V denotes the cache value; Size(i) denotes the size of ith parameter; Fr represents the function of request frequency, as defined in Eq. 2; T now is the current time; and T score is the cache time. ( Fr(i) =

Fr (i) + 1, if hit cache Fr (i ), otherwise

(2)

(3) When the service-invocation information hits, continue to step 4 if the cache fully hits; otherwise, proceed to step 5. (4) Check the location of the cache. If the cache is within the change area, check whether the cache value reaches the threshold value of this area. If so, relocate the cache data from the change area to the resident area. If the cache is in the recycle area, check whether the cache value reaches the threshold value of this area. If so, relocate the cache data from the recycle area to the change area. (5) Update the cache data and replace the information that needs to be recorded to the local cache. Check the cache type and whether the cache value reaches the threshold of this area. If so, relocate the cache in this area. (6) Check whether the invocation path information is cached in the index area. If so, continue to find the response using the cache data. Relocate the cached data with the lowest cache value into the recycle area. Relocate the required cache into the change area. If insufficient space exists in the change area, relocate the cached data from this area to the recycle area according to the cache value. (7) When the cache data is moved out of an area, the routing path of the cached data is retained in the index area. The index area is managed by the least recently used algorithm to improve the efficiency of this area. Multilayer caching. The service network architecture comprises the service switch layer and service router layer. The service switch layer provides access to

Crossover Service Infrastructure: Service Network

133

the service network, and the service switch acts as the service gateway for enterprises. The service router layer is the backbone of the service network and connects different services switches for service cooperation. For given a hierarchical service network, we have discussed service caching in different layers. (1) Service switch caching: The service switch is deployed at the entrance of an enterprise. It caches service data for users with ultralow latency. Similarly, different switches can cooperate with others to improve the overall performance. Once missed, it will forward the request to the corresponding service router. (2) Service router caching: The service router acts as the area manager on the service network. Each service router caches some service data from this area. Once missed, it will forward the request to the destination router. Collaborative Caching. For collaborative caching in an area, part of the cache space in the service node is used to store the service data generated by the local node, and the other is used to store the service data generated by neighbors. The local node maintains an index of the service data cached in other service nodes. In this manner, the cache space of a single node increases to relieve the cache pressure at peak times. Collaborative caching improves the cache-utilization efficiency for the area by expanding the logical cache space and relieving the cache pressure of a single node during peak periods. The main steps of the strategy follow. (1) When the cache space of the service switch node i is insufficient, the cooperative cache process is initiated in this area. (2) The service router maintains the node value of the service switch nodes in the area. The node value is defined as Load i Value(i ) = Value(i )static ∗ ⅀n , i Load i

(3)

where Load i denotes the current load of service node i; n denotes the number of service nodes in the area; and Value(i) denotes the static value of the service node calculated by the network topology. Value(i )static =

n n ⅀ ⅀ R jk (i ) R jk j k/= j

(4)

where Rjk is the number of the shortest paths between service nodes j and k in this area, Rjk (i) is number of the shortest paths passing through service node i, and n is the total number of service nodes in the area. ⅀n V (i ) , (5) Loadi = i=0 ρ where V (i) is the cache value of the service node indicated above, and ρ is the remaining rate of the cache space in the area.

134

S. Pang et al.

(3) Select service node j with the lowest node value in the area. Service node i forwards the service data to be cached to service node j, which will save it and return the specific storage location. Node i records the index . (4) After node i hits the cache, it will initiate a cache hit request to node j through the index with the address of the service requester. Node j returns the result of the service invocation to the service requester after obtaining the address. (5) If a service hotspot occurs in node j, check whether the cache value of service information is greater than the value of the collaborative cache process initiated by node i. If so, node j replaces the collaborative cache and sends a cacheinvalidation message to node i, which reinitiates the collaborative cache process in the area after receiving the message. (6) After the service hotspot in node i disappears, node i initiates a request to all service nodes within the cooperative cache process. The other nodes invalidate the cooperative cache in the local node after receiving this message.

3.3 Service Deployment In a service network, in addition to providing services to other participants through network routing, the service provider can also provide services directly to nearby mobile users through the service switch [12]. A short-distance connection between users and the service switch can dramatically reduce latency, and the computation capability is quite capable of performing conventional tasks. However, the servicedeployment scheme must be considered carefully because service devices connected with service switches may have varying computation or data-storage capacities and the service invokers may have different service preferences—if services are deployed on devices with low-level hardware, the performance of the service network may not satisfy both users and providers [13]. More critically, although application providers can use numerous servers and deploy many instances of a service to provide a better user experience, their cost becomes a major challenge. In contrast, the providers always have clear demands for their applications: they want the applications to maintain key performance indicators (KPIs), e.g., average response time. Thus, we need to determine how to find an appropriate deployment scheme for a service-based application that has low cost while ensuring its KPIs in the service-provisioning system. • Problem Formulation In this scenario, we mainly consider the computation and storage costs of services. The cost of resource consumption can be represented as C(Ω) =

n m ⅀ ⅀ i=0 j=0

γi, j Ωi, j .

(6)

Crossover Service Infrastructure: Service Network

135

We denote γi,j ⩞ αci,j + βdi,j as the cost of instances of different services. By vectorizing γi,j and Ωi,j with the order of the service chain, we obtain two column vectors γ = (γ1,0 , …, γ1,n , …, γm,0 , …, γm,n )T and Ω = (Ω1,0 , …, Ω1,n , …, Ωm,0 , …, Ωm,n )T whose dimension θ is m(n + 1). Then, the cost C(Ω) can be represented as C(Ω) = γT .

(7)

Here, we denote φ = (φs , φ1 , φ2 , …, φm , φe ) as the request path to describe a request’s life cycle, which shows the order of hosts to handle this request. Pφ is the probability of request path φ, and Tφ is the total time for requests that travel through path φ. The average application response time can be represented as E[T] =

n ⅀ n ⅀

···

φs =1 φ1 =1

n ⅀ n ⅀

Pφ Tφ .

(8)

φm =1 φe =1

We investigate Pφ and Tφ to calculate E[T]. Using the definition of Pr ti,j , we can represent Pφ as Pφ =

Pr φs Pr sφs ,φ1

(m−1 Π

) Pr tφt ,φt+1

Pr eφm ,φe .

(9)

t=1

Here, φs means the probability that the nearby service server is sφs . Because the requests always return to the invoker and its nearby server, Pr eφm ,φe does not affect the value of Pφ . Thus, we have Pφ =

Pr φs Pr sφs ,φ1

(m−1 Π

) Pr tφt ,φt+1

.

(10)

t=1

Pφ is different under different local service-routing polices. There are many reasonable routing policies, as different factors are prioritized by different developers. Some common routing policies are described below. Round Robin. Under this policy, the instances of a service on different servers have the same probability to receive requests—if ms1 has one instance on s1 and two on s2 , the probability that request of ms1 goes to s2 is twice that to s1 . Weighted Routing. Under this policy, the processing capability is considered as another factor that can help schedule requests. The probability an instance of a service receives is proportional to processing capability of the server—if ms1 has one instance on s1 , whose processing capability is 200 request/s, and has two instances on s2 , whose processing capability is 100 request/s, the probability that request ms1 goes to s2 is the same as that to s1 , because 1 × 200 = 2 × 100. In this work, we consider the round-robin policy as an example to explain our formulation of the deployment problem. By doing so, we aim to enable developers

136

S. Pang et al.

to follow the process with their own routing policies. It is obvious that Pr φs is dependent on the distribution of application requests; because requests are dispatched to instances according to the volume and processing capability in the round-robin policy, we obtain Pr φs =

Ωt+1,φt+1 Ω1,φ1 λφs , Pr sφs ,φ1 = n , Pr tφt ,φt+1 = n . n ⅀ ⅀ ⅀ λi Ω1,k Ωt+1,k i=1

k=1

(11)

k=0

Each Tφ comprises an access time, routing time, queue time, and backhaul time, as indicated in Eq. 12. Tφ = Taccess + Trouting + Tqueue + Tbackhaul

(12)

The access time comprises two parts: the transmission time between service invokers to their nearby server sφs and the transmission time from sφs to server sφ1 , which caches the instances of ms1 . Therefore, the access time is Taccess =

D1in φ vu s

+

D1in . Bφs ,φ1

(13)

When any instance has finished its work, the result is routed to the next service instance. Therefore, the routing time can be represented as Trouting =

m−1 ⅀ i=1

Diout . Bφi ,φi+1

(14)

The queue time includes the execution time and waiting time. Given processing e can be represented as capacity μi,φi , the execution time Ti,φ i e Ti,φ = i

1 . μi,φi

(15)

• Approach and Algorithm The optimal application deployment scheme is searched to find scheme Ω∗ from the feasible region with minimum cost γT Ω∗ . From the form of P1 , we find that it is a nonlinear integer programming problem, which is NP-complete. Therefore, we turn to approaches that can help find some suboptima. Initially, we relax the constraint of N to R0 (R0 = R − R+ ) to take advantage of the optimization technology for continuous problems. Then, the branch and bound technique is adopted to find the integer solutions. Suppose is the kth element of vector b and Ak is the kth column vector of A. The constraints are denoted as

Crossover Service Infrastructure: Service Network

137

c0 (Ω) = ∊ + T∗ − E[T(Ω)],

(16)

ck (Ω) = bk − Ak Ω.

(17)

Then, we can minimize an l1 -penalty function with a sufficiently large penalty factor υ to solve P1 : ⅀ min Ψ(Ω; υ) = C(Ω) + υ max(−ck (Ω), 0). (18) Ω∈R0

k

Furthermore, by smoothing this penalty function with some elastic variables w and regarding the concatenated vector xP = (Ω, w) as points in the expanded space, we can obtain the smooth version of problem P1 (P2 ): P2 : min Ψ S (Ω, w; υ) = C(Ω) + υ

⅀

Ω∈R0

wk

(19)

k

s.t.ck (Ω) + wk ≥ 0, wk ≥ 0.

(20)

Thus, we can apply the primal–dual interior-point method to find the suboptimal solution of P2 . Specifically, we need to solve a sequence of unconstrained problems (Qt ): ( ) ⅀ ⅀ Qt : minΨ B Ω, w; τt , υ = Ψ S (Ω, w; υ) − τt logwk − τt log(ck (Ω) + wk ), Ω,w

k

k

(21) where the υ is the penalty factor that measures the infeasibility of subproblem Qt , and τt is the barrier factor that manages the constraints shown in P2 . By denoting the primal first-order Lagrange multiplier as →

y = τt (Cdiag (Ω) + Wdiag )−1 1, →

u = τt Wdiag −1 1,

(22) (23)

where vector c(Ω) represents the above constraints for convenience, Cdiag (Ω) and Wdiag are matrices diagonalized from c(Ω) and w. Then the primal–dual function for primal vector xP = (Ω, w) and dual vector xD = (y, u) can be represented as ⎤ γ − JT (Ω)y ⎥ ( ) ⎢ υ−y−u) ⎥ ( Φ xP , xD ; τt , υ = ⎢ ⎣ Cdiag (Ω) + Wdiag y − τt ⎦, Wdiag u − τt ⎡

(24)

138

S. Pang et al.

where J is the Jacobian matrix of c(Ω). Then, we find the suboptimal of the relaxed problem using the primal–dual-based algorithm IDA4ReE. However, because the main process of the ID4ReE is the branch and bound algorithm, it is extremely difficult to determine when the integer solutions occur. Furthermore, if no bounds are available in running this algorithm, the method will degenerate into an exhaustive search. To avoid this situation, we heuristically ⅀ try to solve an integer linear programming (ILP) problem with objective max θi Ωi and constraints c1∼k (Ω) ≥ 0. This is because the application is more likely to have a smaller average response time if more microservice instances are deployed in the system. By selecting solutions that have c0 (Ω) ≥ 0 from this ILP’s solution set, we can roughly obtain the initial upper bound.

3.4 Dynamic Service Adaptation In crossover service convergence, composite services based on processes play an increasingly important role. More enterprises are deploying their business in the form of Web services in the network to provide basic functional modules for the realization of a complex business. Although services from different organizations may perform the same function, their service structures and processes can differ greatly. To simplify the service-invocation process and adapt to the dynamic characteristics of the service, we propose reference service process technology, which is a standardized process abstracted from multiple service processes with the same or similar goals. Based on graph theory and semantic similarity, we propose a reference service process to solve the problems faced by developers when implementing a complex business [14]. The overall framework, as shown in Fig. 20, is composed of three key steps: reference service extraction, service process hypergraph modeling, and reference service process extraction. Initially, for atomic services with the same function, we propose a mapping strategy between reference services and general services based on semantic similarity. According to the mapping results, we replace the services in the general process with the corresponding reference services. Then, based on graph theory, we integrate the subgraphs of the processes into a global hypergraph and propose an optimization algorithm to decrease the redundancy of the hypergraph based on weights. Finally, by disassembling the optimized hypergraph, we extract the reference service process and formulate a strategy for process invocation and execution. • Reference Service Construction From the perspective of graph theory, the atomic services in the service process are represented by points in the graph, while the sequential execution relationships of the services are edges. As more enterprises deploy their business to the network, there are

Crossover Service Infrastructure: Service Network

139

Fig. 20 Framework of reference service process-construction method © [2022] IEEE. Reprinted, with permission, from Ref. [5378090933963]

an increasing number of services with similar functions in the service-registry center. Although the functional modules of different service processes for the same topic are very similar, different services may be selected according to different concerns. Although they belong to the same topic, the graphs corresponding to different service processes may have few intersections, which makes it difficult to extract the reference service processes. Processes in a service-process cluster are composed of services within a service cluster. Definition 1 A reference service is an abstraction of services in a certain topic cluster. It can map input or output attributes with the same content but different names across different services to a set of reference attributes, which provides a mapping relation between the general and reference services.

140

S. Pang et al.

To construct the reference services, we first need to vectorize the attributes of the general services and map them into vector space using the word2vec algorithm [15], which is a neural network model used to generate word vectors. It includes the Word Bag strategy, which measures the semantic-representation vectors of the target words by the words around them, and the Skip-Gram strategy, which measures the semantic-representation vectors for the surrounding words starting from the current word. In this paper, we take advantage of the Skip-Gram strategy to calculate the joint probability between the vector of an input target service word and the vectors of several output service words, which is used to optimize the parameters of the neural network and adjust the word vector itself. Based on the semantic distance in vector space and the K-nearest neighbor algorithm [16], we can cluster the attributes. We map the attributes in each cluster to a reference attribute corresponding to the reference service. Small-scale clusters or noise points in the vector space are treated as the negligible attributes of the service. When services with these negligible attributes are called by the reference service, a default value is given to ensure the normal execution of these services. The reference and general services are mapped, the heterogeneity between service processes can be greatly reduced. • Reference Service Process Extraction In the previous section, we leveraged the most basic linear service process to explain how reference services can increase the intersection of general processes. However, real service processes often have more complex business logic. To better extract the reference service process, we define the general service process below. Definition 2 A general service process can be defined as a quaternion P = {I, M, T, J}, where I represents the initial service, M represents the intermediate service, T represents the terminated service, and J = {And-split, Xor-split, Loop-split, And-join, Xor-join, Loop-join} represents the jump logic of the services in a process. Generally, there are four common control flow patterns in a process model: sequential, parallel, conditional, and loop patterns, which are labeled as Sequence, And, Xor, and Loop, respectively [17]. Each task node in a sequential pattern has exactly one incoming arc and one outgoing arc. A conditional pattern starts from an Xor-split node and ends at an Xorjoin node, while a parallel pattern starts from an And-split node and ends at an Andjoin node. The execution of the task nodes in a parallel pattern can be simultaneous or in any order. A loop pattern has a single entry and exit point, starting from a Loop-split node and ending at a Loop-join node. The nodes in a loop pattern are executed repeatedly. The process model shown in Fig. 21 contains sequential, conditional, and parallel control flow patterns. The highest abstraction level is a sequential pattern, consisting of task A, a parallel pattern, and tasks E and F, which are executed sequentially. The

Crossover Service Infrastructure: Service Network

141

Fig. 21 Execution sequence of a service process

parallel pattern contains a conditional pattern and task B, where tasks C and D form the conditional pattern. Definition 3 Hypergraphs can represent any association, including one-to-many and many-to-many relationships. A hypergraph is defined mathematically as follows: Suppose V is a finite set of objects and E is a set of subsets in V. We call G = (V, E) a hypergraph, where V is a set of points and E is a set of edges. By building a hypergraph for all service processes of the same topic, we can achieve their logical integration. However, the hypergraph still contains too much unimportant or redundant information, which hinders the extraction of reference service processes. Therefore, we propose a statistical weight-reduction algorithm that performs multiple rounds of traversal along the hypergraph to trim the weights of those logical relationships with fewer jumps. Each traversal comprises four steps: (1) Find the vertices that have served as the starting service most but have not been traversed yet. (2) Check all the jumps starting from this point. If the number of jumps for a certain logic is less than a given threshold, then these edges and the subsequent jump relations triggered by them are cut off. (3) The end point of the previous jump serves as the starting point and the optimization operation continues. (4) Repeat the above steps until the termination solution point is encountered. If there is no jump relationship with a weight below the threshold in the current hypergraph or all of the initial services have been traversed, the entire optimization process ends. Based on the optimized hypergraph, we can finally construct the reference service process as defined here. Definition 4 A reference service process is a 5-tuple SSP = {ssp-i, ssp-e, ssp-s, ssp-j m, ssp-c}, where ssp-i contains all the initial reference services, ssp-e contains all the terminal reference services; ssp-s contains the remaining reference services; ssp-j m contains the service jump information starting from service m, including jump logic

142

S. Pang et al.

and target services, and is maintained on the node of service m; and ssp-c contains the configuration files required by the reference service process while calling a general process, including the transformation of input and output formats, to ensure smooth operation. The reference service processes can quickly traverse the path of “start service → jump logic → intermediate service → terminate service” and establish connections with all mapped general service processes. Meanwhile, developers do not need to worry about the internal execution of a service process and only need to call the reference service process according to the reference calling method. The reference service process can quickly establish a connection with the general service process with the best QoS to provide the developer with the best business solution. As shown in Fig. 22, there are two ways a developer can invoke a reference service process. In the first case, there exist general service processes that can meet the developer’s needs (business requirements, QoS, etc.). The reference service process establishes a corresponding relationship with this general process according to its execution logic, and a local process-execution logic (including the reference service and jump logic) is constructed. The developer inputs information, which is converted into a format appropriate to the initial reference service, to the reference service process. Based on the execution logic of the reference service process, the business service is executed and the result, which is also standardized through the configuration file, is output to the developer. In the second case, there is no general service process that can meet developer needs. According to the reference services in the reference service process, an atomic

Fig. 22 Invocation and execution of reference service process

Crossover Service Infrastructure: Service Network

143

service that meet the needs are found from the service-registry center, and a set of logic jump relationships maintained by each service node is used to automatically build the desired service process. Finally, a group of processes ranked by QoS will be recommended for developers to choose. Consider user registration in the e-commerce scenario as an example (Fig. 23). The services of different e-commerce platforms require different processes and information, which creates a burden for the user. According to the method proposed above, we extract the reference registration service from the registration services of different ecommerce platforms. Because “nation” information appears the least, it is considered a negligible attribute and discarded, as shown in Fig. 24. We model the hypergraphs and minimize the redundancy of service processes that have undergone service standardization. Because the weight of the edge connected with the “Developer Review Service” is very low (weight = 1), it is treated as an unimportant service and is cut off with the edge. According to the correspondence between reference service processes and hypergraphs, we can extract the reference service process of the online registration business. Figure 25 shows the contents of the reference service process and its mapping relationship in the prototype system we have developed.

Fig. 23 User registration on different e-commerce platform

144

S. Pang et al.

Fig. 24 Registration reference service mapping

Fig. 25 Registration reference service process

4 Summary This chapter first discusses the background and challenges of the crossover service runtime environment convergence and then proposes a model and architecture for the service network. The e-health case study provides an intuitive explanation of how the

Crossover Service Infrastructure: Service Network

145

service network works. To achieve efficient opening and access of crossover services, we propose web service packaging methods and access theory for IoT services. Finally, we propose a series of service network-optimization measures to ensure the efficient and stable operation of large-scale service networks, including servicerouting methods, service-caching techniques, service-optimization deployment, and dynamic service adaptation.

References 1. Oh S-C, Lee D, Kumara SRT (2008) Effective web service composition in diverse and largescale service networks. IEEE Trans Serv Comput 1(1):15–32 2. Yin J, Zheng B, Deng S, Wen Y, Xi M, Luo Z, Li Y (2018) Crossover service: Deep convergence for pattern, ecosystem, environment, quality and value. In: 2018 IEEE 38th International Conference on Distributed Computing Systems, pp 1250–1257 3. Zheng B, Yin J, Deng S, Wu Z, Dustdar S (2020) A service-oriented network infrastructure for crossover service ecosystems. IEEE Internet Comput 24(1):48–58 4. Zhao L, Cheng B, Chen J (2020) Service-oriented IoT resources access and provisioning framework for IoT context-aware environment. In: IEEE World congress on services (SERVICES), pp 245–251 5. Cheng B, Wang M, Zhao S, Zhai Z, Zhu D, Chen J. Situation-aware dynamic service coordination in an IoT environment. IEEE/ACM Trans Netw 25(4):2082–2095 6. Balakrishnan H (2001) Chord: a scalable peer-to-peer lookup service for internet applications. In: ACM SIGCOMM 7. Li M, Yu B, Rana O, Wang Z (2008) Grid service discovery with rough sets. IEEE Trans Knowl Data Eng 20(6):851–862 8. El Kholy M, Elfatatry A (2015) Intelligent broker a knowledge based approach for semantic web services discovery. In: International conference on evaluation of novel approaches to software engineering, pp 39–44 9. Blankstein A, Sen S, Freedman MJ (2017) Hyperbolic caching: flexible caching for web applications. In: USENIX Annual technical conference, pp 499–511 10. Bin G, Zhou Z, Fangming L, Fei X (2019) Winning at the starting line: joint network selection and service placement for mobile edge computing. In: IEEE INFOCOM 2019-IEEE conference on computer communications, pp 1459–1467 11. Ting H, Khamfroush H, Shiqiang W, La Porta T, Stein S (2018) It’s hard to share: joint service placement and request scheduling in edge clouds with sharable and non-sharable resources. In: IEEE 38th International conference on distributed computing systems, pp 365–375 12. Fan Q, Ansari N. Application aware workload allocation for edge computing-based IoT. IEEE Internet Things J 5(3):2146–2153 13. Yang W-P, Wang L-C, Wen H-P (2013) A queueing analytical model for service mashup in mobile cloud computing. In: Proceedings of the IEEE wireless communications and networking conference, pp 2096–2101 14. Pang S, Yin J, Zheng B, Zheng T, Tian Q (2020) Reference service process: a normalized crossover service collaboration paradigm. In: International conference on service science (ICSS), pp 9–15 15. Rong X (2014) word2vec parameter learning explained. arXiv:1411.2738 16. Dudani SA. The distance-weighted k-nearest-neighbor rule. IEEE Trans Syst Man Cybern 4:325–327 17. Fan J, Wang J, An W, Cao B, Dong T (2017) Detecting difference between process models based on the refined process structure tree. Mob Inf Syst

Crossover Service Optimization: Value and Quality Min Li, Zhiying Tu, and Zhongjie Wang

Abstract Under the background of deep convergences in crossover services, the start point and end point of multi-participant collaboration are all to achieve the winwin of service values. In crossover services, service providers in different domains give full play to their advantages of service capability and quality to create rich service values, which are further transmitted and transformed based on complex service collaboration patterns and business interaction processes, and finally realize the capability complementarity and value co-creation of multi-stakeholders. At the same time, it also provides consumers with more abundant service functions and more reliable service value guarantees. Therefore, the focus of this chapter is on how to fully utilize the service capabilities of multiple participants and maximize the service value/quality of multiple stakeholders. The main challenges of crossover services optimization are the complex dependencies between multiple participants and their differentiated service expectations. This chapter focuses on the three stages of service design, configuration and operation, and gives a total of 7 optimization methods that define different optimization objectives and give different solutions for the global crossover service, local multi-participants and consumers. Keywords Value–quality–capacity (VQC) modeling · Value/quality alignment · Value/quality conflict resolution · Value/quality negotiation · Value/quality configuration optimization To achieve cross-domain, cross-organization, cross-platform, and cross-system operation, different service providers form a crossover service to share resources and splice business processes in accordance with a specific collaboration pattern to provide more plentiful service content and smoother business process. The value M. Li · Z. Tu (B) · Z. Wang Harbin Institute of Technology, Harbin, China e-mail: [email protected] M. Li e-mail: [email protected] Z. Wang e-mail: [email protected] © Zhejiang University Press 2023 J. Yin et al. (eds.), Convergence in Crossover Service, Advanced Topics in Science and Technology in China 68, https://doi.org/10.1007/978-981-19-8844-8_5

147

148

M. Li et al.

created by each service participant in each part of the business process can be transmitted and transformed throughout the service network, which can even create new value. From the perspective of value and quality, this chapter discusses a series of optimization problems at different stages of crossover services, including alignment and conflict optimization in modeling, negotiation and configuration optimization during design, and perception and continuous optimization in running. From idea to construction, a crossover service must undergo multiple rounds of organization, modeling, design, monitoring, and reconfiguration; different stages face challenges at different levels and technologies. The main challenges faced by value/quality integration and optimization are as follows. (1) The heterogeneous problem of multidomain participants’ service VQC evaluation system: Services in different fields need to cooperate, which requires them to eliminate conflicts, create cross heterogeneity, and achieve business convergence. However, there are different temporal–spatial–domain (TSD) boundaries among multiple services with different quality attributes and evaluation methods. When these services enter the same crossover service and collaborate across domains, it is necessary to integrate service VQC semantics and quantitative methods and unify the evaluation standards and measurement space. (2) The optimal configuration problem of value–quality–capacity for participants at different levels: The purpose of service convergence is to maximize the service value of all parties, but the value evaluation systems of each participant differ; thus, there may be explicit or potential value conflicts between them. It is necessary to measure and weigh these conflicts based on the existing capabilities of individual services to meet the different levels of service expectations in sequence according to reasonable rules, utilize the advantages of each participant to maximize the global service value, and ensure that the interests of local participants are not compromised. (3) The variation in delivered service value/quality and exception-tracking issues: The optimal service VQC configuration of each participant designed in the modeling stage is often static and idealized. The characteristics are distinct from those presented in the actual service-delivery process and fluctuate dynamically within a certain range. Therefore, we must continuously monitor the time-varying characteristics and spatial distribution of service value and quality to identify defects in service configurations and trace the source to ensure the performance and reliability of service during the running state. Further, it is helpful for each subject to carry out continuous quality management and value improvement through continuous reconstruction and evolution to maintain stability of the service value/quality. In summary, this chapter focuses on the evaluation, configuration, perception and continuous optimization of crossover service VQC as oriented to TSD dimensions. The following sections describe the problem analysis, theoretical innovation, and technical implementation, by modeling a VQC evaluation system for a

Crossover Service Optimization: Value and Quality

149

crossover service, resolving inconsistencies and conflicts among multiple participants, researching crossover value/quality optimal configuration through computation and negotiation; monitoring value and quality based on discrete spatiotemporal information and tracking exceptions, cost-constrained quality control, and continuous value improvement to support the quality and value convergence of the crossover service.

1 Service Value and Quality A crossover service is a process in which multiple participants break through the original service boundaries, including organizational boundaries, domain boundaries, platform boundaries, geographical boundaries, and conducts crossover convergence on the premise of maintaining original autonomy. Consumer demand is often diverse and can be divided into multiple demand segments, each of which contains functional and nonfunctional requirements. On the service side, different service functions are often implemented by service providers in different domains. Even for the same function, different providers provide different service qualities and capabilities. Hence, crossover services are based on multiple service providers and the crossing of boundaries. From this background, we face two main challenges in crossover service VQC modeling. (1) At the service model framework, we should consider how to define the service VQC model and its relationships with the function model, the “boundary” that is unique to crossover service, and the impact of service cross-domain on service VQC. (2) At the modeling level, we must determine how multidomain individual services can efficiently collaborate to quickly model a complex crossover service based on their existing domain’s prior models. After substantial demand research and practical analysis, this chapter provides a crossover service value/quality model framework and a multiparticipant collaborative modeling method.

1.1 Value and Quality Modeling Framework The service model describes service functions and nonfunctional attributes. Many modeling specifications and standards have been proposed, including the commonly recognized BMM,1 VDML,2 DMN,3 and BPMN.4 The content and potential relationships of these model specifications are shown in Fig. 1.

1

Business motivation model (BMM), https://www.omg.org/spec/BMM/. Value delivery modeling language (VDML), https://www.omg.org/spec/VDML/. 3 Decision model and notation (DMN), https://www.omg.org/spec/DMN/. 4 Business process model and notation (BPMN), https://www.omg.org/spec/BPMN/. 2

150

M. Li et al.

Fig. 1 Association and extension relationships among existing model specifications

In the BMM, Influencers characterize the reasons for service adjustments, then Ends answers to build what kind of service, and finally Means (capability configuration) explain how to implement services. In addition, Assessments are used to evaluate the service completed by different people at different times and provide feedback to the Influencers and Ends. The BMM interpretation of What and How is vague, and the assessment and audit relationship between How and Assessments is unclear. VDML compensates for this problem by illustrating the relationship between the service value and capability configuration from the perspective of value delivery and explaining what service capability business activities rely on to add value. However, VDML’s description of the action arrangement is too concise. BPMN can supplement this part by detailing the timing constraints and information interactions among business activities. However, the descriptions of business rules are not detailed in the BPMN. DMN can complement BPMN by providing decision-making rules. The above models cover many aspects of service modeling and complement each other to create detailed model elements, but there are still two major problems. First, although VDML talks about nonfunctional attributes (service value and capability), it only focuses on qualitative relationships between them and business activities. It does not discuss quantitative methods in detail. Second, the above models only consider time and place in the business execution phase, but ignore them when defining nonfunctional attributes, while evaluation criteria of service VQC vary greatly in different TSD. Different research teams have different names and understandings of service domains, including service context, service domain, time-aware service, and location-aware service. They all express a similar meaning, that is, the dynamic and contextual dependency of a service’s functional and nonfunctional attributes. Many scholars have realized the importance of domain characteristics to service modeling and provided theories and tools to support multidomain modeling. They construct service domain features through data mining and information reasoning [1, 2]. After

Crossover Service Optimization: Value and Quality

151

Fig. 2 Framework of a crossover service model oriented to TSD features

a period of service execution, business execution data is used to mine the domain features of nonfunctional attributes and apply them to the service recommendation, which lags behind and is not conducive to including domain features into the scope of service design and optimization during the modeling process. To date, TSD features have received little attention; however, they are highly significant to service execution and evaluation, especially in the context of crossover services. Therefore, our work divides the crossover service model into three parts— the functional, nonfunctional, and TSD models—as shown in Fig. 2. In accordance with the acknowledged BPMN2.0 modeling specification, this framework does not extend additional model elements for the functional model and only conducts in-depth analysis on the modeling level, as shown in Fig. 3. The annotation of nonfunctional attributes and TSD to the BPMN process is implemented in the modeling tools. The associations between TSD and functional models are reflected in three aspects: • Collaborating characteristics. The organizers of the crossover service first design the overall choreography process according to the common demands of consumers and the common cooperation patterns of participants, as well as abstract the basic functional modules into collaboration nodes. The result of refinement is not unique, but can be combined in different ways according to the TSD condition. • Execution characteristics. Business execution process modeling further refines the service processes to the executable level. Each participant models its own business execution steps and resource scheduling policies in detail. In business process

152

M. Li et al.

Fig. 3 Functional model hierarchy construction

modeling, start nodes have trigger times, and activities have execution constraints on time and space; thus, business fragments can be integrated in different ways under different TSD conditions. • Scheduling characteristics. General resources have their own specific scheduling rules. Especially in entity services, resources are limited rather than being requested indefinitely, and the number and specifications of schedulable resources differ under different TSD conditions. Quantitative modeling of nonfunctional attributes is conducive to service decision making and optimization. In this book, indicators are used to quantify, measure, and evaluate the service VQC. The relationship between the TSD and nonfunctional models is reflected in the specific distribution characteristics of the indicators, as shown in Fig. 4. For example, Hema adopts a hierarchical operation system to develop multiple versions of stores for different business districts and income levels, including supermarkets, food markets, ministores, and small stations. Different stores have different product variety, preferences, and quality, and are patronized by diverse consumer groups, so the customer flow and daily turnover also differ. A crossover service is not executed under a single specific domain, but through cross-domain collaboration. BPMN explains that it is very difficult to formulate a universal and complete service model specification for multiple domains, so we attempt to model the most basic service domains and fully consider how to characterize the impact of cross-domains on the functional and nonfunctional attributes. In this book, transboundary features are defined in the form of basic model elements, including the temporal, spatial, and generalized domains. We can use some common distributions to characterize the distribution of the service VQC on different TSD features, as shown in Table 1.

Crossover Service Optimization: Value and Quality

153

Fig. 4 Distribution differences of indicators on TSD features Table 1 Common distribution characteristics of indicators Distribution shape

Distribution type

Distribution function

Examples

J-shaped distribution

Monotone increasing

Beta or gamma

The products are mostly fresh, and the probability of spoilage is low

Monotone decreasing

Beta or gamma

A long delivery delay is unlikely to occur

Straight distribution

No monotony

Uniform

The wait for a settlement at each counter is equally probable

U-shaped distribution

U-shaped

Beta

The probability of failure is high when mechanical parts are first used, then tends toward a stable state with a low probability, and increases to a high probability after long-term use

Bell-shaped distribution

Normal distribution

Normal

Delivery time is generally around 30 min

Right-skewed distribution

Beta

In the monthly consumption quota, there are very few parts under 300, most parts are between 300 and 800, and there are very few between 800 and 3000

Left-skewed distribution

Beta

In user ratings, there are very few within 1–3 points, most are between 4 and 4.8, and there are rare cases where 5 points can be obtained

154

M. Li et al.

1.2 Collaborative Modeling Process This section summarizes the objective problems faced by crossover service modeling and proposes a collaborative modeling solution, which aims to fully utilize each participant’s domain expertise to implement complete, flexible, and efficient modeling. From a modeling perspective, we analyze the general concerns of crossover service modeling to explain the necessity of collaborative modeling. • Crossover Feature. The original services are discrete, independent, autonomous, and heterogeneous, but now cross natural boundaries to establish cooperative relationships in accordance with a service or requirement pattern. The Domain with the green border in Fig. 5 is a crossover feature, which determines that the crossover service modeling requires the participation of multidomain and multiservice modelers. • Global Constraint. Simple model splicing does not guarantee that the global expectations of the crossover service are met to the fullest extent by the local expectations of multiple participants. To avoid inconsistencies or conflicts during model convergence, individual services should be modeled without violating the constraints of the global model, as shown within the yellow border in Fig. 5. • Local Independence. Crossover service modeling does not redesign a new service from zero, but exploits the unique advantages of existing services in their respective domains to build collaborative relationships. The original service model elements, such as business processes, execution logic, and resource dependencies, do not change significantly, as shown in the gray border in Fig. 5. • Hierarchical Dependency. During implementation, the crossover service has multiple layers of dependency, including the global crossover service, collaboration nodes, service domains, participants, business segments, resources/roles, and other layers. From top to bottom, the service model is continuously enriched and refined, while from bottom to top, the service model is constrained layer by layer. The hierarchical dependence determines collaborative modeling steps. • Changeable Collaboration. More often than not, a crossover service does not correspond to a unique service model or service composition, as indicated in orange in Fig. 5. Because of rapid changes in consumer demand, the service market, and implementation technology, the VQC of both global and local services change. Thus, the establishment of a stable service model is not the ultimate goal. A model that can be built flexibly and maintained dynamically is more suitable for the current service environment. To summarize some concerns of collaborative modeling, we propose a collaborative modeling approach for the crossover service, as shown in Fig. 6. The modeling work is mainly divided into the Schema and Instance layers. In the model of the Schema layer, the global VQC expectation is decomposed into several collaboration nodes. Each node is implemented by service providers from multiple domains, who

Crossover Service Optimization: Value and Quality

155

Fig. 5 General concerns of collaborative modeling of a crossover service

establish a flexible collaboration based on the service alliance contract or the principles of capability complementarity or value matching. In the model of the Instance layer, each participant has the enterprise service specification and industry service standard as the original model information. Each participant then extracts business segments that can be independently executed and create value from the original process, and annotates the segments with the local service VQC. Finally, they hide their own core business information and expose the service VQC related to partners as the bottom line of negotiations. In the negotiation stage, the multiparty participants of each collaboration point discuss the relevant VQC indicators to ensure that the current collaboration meets the value expectations of the multiparty participants.

156

M. Li et al.

Fig. 6 Overview of collaborative modeling of crossover service

Fig. 7 Example of the “retail + catering” business process model and annotation

To support crossover service modeling oriented to TSD features, we developed a visual modeling and annotation tool that was extended based on activiti-modeler.5 Then, we model and annotate Hema as an example using this tool, and the result is shown in Fig. 7. For details about the model and tool usage, please refer to tool’s webpage.6

5 6

https://github.com/Activiti/Activiti/tree/5.x/modules/activiti-modeler. http://60.205.188.102:16038/modeler.html?modelId=1.

Crossover Service Optimization: Value and Quality

157

2 Value/Quality Alignment and Conflict Optimization Model interoperability is the precondition for the exchange of data and information among multidomain participants to reach a consensus on the service requirements and goals, as well as establish a stable cooperative relationship and a reliable cooperation pattern. The service evaluation system comprises several statistical indicators to measure and evaluate the VQC, which is effective reference information for service decision making and optimization. Each indicator contains not only rich semantic information, but also detailed qualitative and quantitative description information. Different participants have their own norms and habits in the definition, interpretation, quantification, and weight settings of indicators. The precondition for cross-domain cooperation between parties is to realize the alignment of semantics and quantitative methods of service evaluation indicators in order to ensure that the content expressed by each other’s indicators and the meanings of the values can be accurately understood during multiparty cooperation. In addition, there are many dependencies between the collaborators in the crossover service in terms of service VQC. Because of these dependencies, the realization of each participant’s local objectives is related not only to its own service quality and capability but also to the collaborators’ and global quality and capability. Furthermore, the global objectives depend on multiple participants’ indicators. Therefore, when multidomain participants establish a collaborative relationship to achieve crossover services, they should verify whether (1) their own goals are compromised by participating in the collaboration; (2) their own service indicators can meet the requirements of the other collaborators; (3) their own service indicators can meet the overall requirements of crossover services; (4) their own goals can be improved by participating in the collaboration. The first two considerations are the access principles, that is, prerequisites to meet the overall requirements while maintaining their own service advantages. The third is the withdrawal principle, which states that participants must withdraw when their own interests lose too much, and the fourth is the adjustment principle, according to which participants should undertake more indicator adjustment obligations to resolve conflicts and optimize the overall goals when their own interests may be better. However, in the actual service-convergence process, the first three criteria may not be met simultaneously, that is, conflicts may occur. This section proposes solutions for multiparticipant crossover fusion from the perspective of value/quality alignment and conflict optimization.

2.1 Value/Quality Alignment The problem of multiparticipant heterogeneous model alignment, also called model interoperability, includes technical and semantic interoperability. The former is mutual conversion of models constructed based on different frameworks and

158

M. Li et al.

grammars, while the latter mainly focuses on using ontology as a semantic model [3] and establishing domain ontology through ontology-reconstruction techniques such as ontology hybridization, synthesis, and mutation [4]. Ontology-based semantic mapping rules are used to realize semantic alignment between heterogeneous enterprise models, including term alignment, concept granularity alignment, angle alignment, and coverage alignment [5]. However, there are major challenges to construct an ontology based on the existing methods and tools. It is difficult to maintain the accuracy and integrity of a vertical domain ontology during its construction [6], which directly affects the semantic alignment. Unlike traditional ontology-based approaches to semantic interoperability of models, our work does not rely on ontology construction. Our method extracts the key elements of service contents, business activities, evaluation aspects, and evaluation rules through natural language processing technologies from known multidomain and multiparticipant service evaluation systems. Then, based on the public, domain, and custom dictionaries, the morpheme relationship among four types of phrases is calculated. Finally, the semantic relationship among indicators is determined and the confidence is calculated according to the morpheme relationship matrix. Finally, the semantic relation network of multidomain and multiparticipant indicators is obtained. The input of the preprocessing stage is a sentence Si that is the definition and explanation of an indicator. The purpose of word segmentation is to extract all the words contained in the sentence and remove unnecessary stop words to obtain word group WG. During part-of-speech tagging, important words containing actual semantics, such as nouns, verbs, quantifiers, adverbs, adjectives, and conjunctions can be identified from WG that correspond to the service content phrases WGservices , business activity phrases WGbusiness , evaluation aspect phrases WGindicators , and evaluation rule phrases WGadjunctword . Modification relationships among different parts of speech can be obtained in the dependency-parsing stage. • Service contents are generally represented by proper nouns and include the roles involved in the service implementation, the resources on which the service execution depends, and the tangible products or valuable knowledge information accompanying the service delivery process. • Business activities are actions related to business execution, referring to actions performed by roles or automated mechanical systems, and are usually represented by verbs. • Evaluation aspects are nouns that modify service contents or business activities, generally with specific suffixes, such as the rate, degree, or probability of X. • Evaluation rules are indicators that often have specific evaluation frequencies and objects, such as a daily, monthly, or annual average or items per person, order, or case. After preprocessing, to determine whether there is a certain semantic relationship between indicators I n and I m , we first calculate the semantic relationships between similar phrases WGk n and WGk m , where k ∈ {services, business, indicators, adjunct word}. This section summarizes the semantic relationships of words within different phrases as described in Table 2.

Crossover Service Optimization: Value and Quality

159

Table 2 Common morpheme relationships for the four key phrases Key phrase

Morpheme relationship

Explanation

Examples

Service contents

A kind of

A is a kind of B, A is a hyponym of B, and B is a hypernym of A

“Ingredients” and “meat products”

A part of

A is a part of B, B “Dishes” and “drinks” contains A, A is a part and B is a whole

The same kind of

A and B have a common “Dishes” and “meat abstract parent class in the products” tree-like upper–lower relationship

Similarity

Synonymous but different “Supermarket” and forms, A and B express “mall” highly similar or equivalent meanings

Correlation

The source is related, A is “Dishes” and the raw material of B, and “ingredients” B is processed by A

Business activities

Evaluation aspects

Evaluation rules

Use/tool-related, A is a tool of B-related business

“Dishes” and “refrigerators”

Composition/total-part related, A is the accessories that B must include

“Delivery cart” and “incubator”

Temporal dependencies

A is the preorder activity of B, B is the successor activity of A

“Packaging” and “delivery”

Synchronous dependencies

Activities A and B must “Dishes are packaged” be synchronized in time or and “rider arrives at the space before subsequent restaurant” activities can be started; otherwise, one party must wait

Compensatory dependencies

An error in A triggers the execution of B. If A is correct, B is not executed

“Confirmation of receipt” and “after-sales service”

Synonyms

A and B express the same or similar concepts

“Correct rate” and “accuracy rate”

Antonyms

A and B express opposite concepts

“Error rate” and “accuracy rate”

Transforming relationship

A and B belong to the same class of quantifiers, so they can be converted with the help of conversion formulas

“Daily average” and “monthly average”

160

M. Li et al.

The judgment of the relationship between indicators is mainly based on three types of dictionaries: public, domain, and custom. The vocabulary richness, lexical relationship detail, lexical explanation detail, and lexical organization of the dictionaries all affect the reliability of the calculated results. Therefore, this section selects the synonym Cilin (extended version), HowNet, and Baidu dictionaries as public dictionaries for reference. The Sogou and Baidu industry dictionaries are used as domain dictionaries for reference. Finally, the semantic relationships among the indicators are determined according to the morpheme relationship of the keywords. This section defines three major categories and nine subcategories of the relationships among indicators at the semantic level, as listed in Table 3. When the sample data of indicators under different TSD conditions are known, the purpose of quantitative alignment is to define the TSD features, divide the service domains, and use the kernel density estimation to fit the TSD characteristic distributions of the indicator in the single domain and rich domain. According to the fitted probability density, the probability distribution function is solved, and then the corresponding values of the indicator under different TSD characteristics are solved based on the quantile. The mapping relationship between the specific value of the indicator and the actual service level is neither unique nor constant. The same indicator value may also correspond to different service levels and different service levels may take the same value under different TSD conditions. For example, there are obvious differences in the delivery efficiency and delivery time in different time, space, and domains. For example, efficient delivery takes 20 min during the offpeak dining period, 30–40 min during the peak dining period, and 50–60 min at midnight. If the difference in the TSD characteristic distribution of the indicators is not considered, the service decision making and optimization may fail or be imbalanced. For example, if an enterprise formulates a unified strategy for commodity price increase across the country, low-income areas will experience a significant increase in prices, but high-income areas will not feel a significant difference. With the aid of the quantitative alignment method mentioned in this section, the decision makers can perceive the distribution difference of the indicator value in different time and space boundaries and formulate a reasonable enterprise decision plan according to the alignment-mapping function. Generally, the distribution type of sample data cannot be predicted in advance, nor can it be determined how many peaks exist in the distribution curve, so the general parameter estimation method is not practical. We use kernel density estimation for nonparametric estimation and the Statsmodels python library to achieve probability distribution fitting. We select “gau” as the kernel function and “scott” as the bandwidth calculation function. When inputting the sample data DataSet d ' , with the help of the KDEUnivariate function, we can fit the probability density function pdf d ' and probability distribution function cdf d ' of the indicator on service domain d ' . On this basis, we have obtained the characteristic distribution of indicators in different service domains of time and space. Next, we need to use these distribution functions to establish the corresponding relationship between the indicator values. Our method takes quantile

Crossover Service Optimization: Value and Quality

161

Table 3 Nine categories of semantic relationships between indicators Semantic relationship

Subcategories

Explanation

Examples

Similar relationship

The same indicators

The service content, business activity, evaluation aspect, and evaluation rule all correspond and have highly similar semantics

Dish-packing rate, food-packaging efficiency

Conjugate indicators

The service content and business activity are highly similar, but the evaluation aspects of indicators are antonyms of each other

The cleanliness of the restaurant, the amount of clutter in the dining environment

Superior and The business activity and Product defect rate, subordinate indicators evaluation aspect are fresh defect rate highly similar, but there is a subordinate relationship between service contents (word A is a component of word B, or word A is a subcategory of word B) Correlative relationship

Correlative of service content

The business activities Chef’s health, food are similar (if they exist), hygiene the evaluation aspect of the indicators are similar (weaker than the similar degree of approximation), and there is a correlation between the service contents

Correlative of business activity

The service contents are similar, the evaluation aspects are similar, and there is a correlation between business activities

Correlative of indicators

There is no obvious Delivery time of correlation between the dishes, delicacy of service content or dishes business activity, but the indicator’s description contains accompanying words such as “with X,” “more X,” or “less X,” which indicates that there is a correlation between the two indicators

The firmness of food packaging, probability of dish being transported without damage

(continued)

162

M. Li et al.

Table 3 (continued) Semantic relationship

Subcategories

Explanation

Examples

The same category

The same category of service contents

The service evaluation is The accuracy of food similar in aspect, but the packaging, order service content and accounting accuracy business activities are neither similar nor correlative, or there is no mention of the service contents or business activities. In this case, the same category relationship can be roughly defined

The same category of business activities

The business activities are similar, but the service content and evaluation aspects are neither similar nor related

Accuracy of food packaging, food packaging firmness

The same category of indicators

The service content is similar, but the business activities and evaluation aspects are neither similar nor related

Product storage time, proportion of finely processed goods

α as the alignment benchmark, assumes that indicator I presents two distributions cdf(I a ) and cdf(I b ) on service domains a and b, and inverts the probability distribution function to obtain a function with α ∈ [0, 1] as the independent variable. Each quantile α ' corresponds to the indicators values, I a ' and I b ' , such that the correspondence between indicators’ values on the two service domains can be established, as shown in Fig. 8.

Fig. 8 Example of quantile-based quantization alignment of indicators

Crossover Service Optimization: Value and Quality

163

2.2 Conflict Detection, Measurement, and Resolution Many scholars have recognized that complex service dependencies lead to conflicts and have attributed conflict to mutually exclusive service objectives, thus transforming conflict resolution problems into multiobjective optimization (MOO) problems. Jatoth reviewed the application of MOO in service composition and selection [7]. MOO problems are generally NP-hard, but the heuristic intelligent algorithm can efficiently obtain feasible solutions. Liao [8] proposed a lightweight particle-swarm optimization (PSO) algorithm to select services with approximate distance and an external archive mechanism. Another strategy is to convert multiobjective problems into single-objective problems. For example, the decomposition-based multiobjective evolutionary algorithm (MOEA/D) has shown advantages in multiple application scenarios [9, 10]. However, in the experiments, we found that conflict resolution and MOO are not completely equivalent. In addition, to understand a conflict in simple terms, the conflict must be quantifiable; the quantitative results can be used to guide conflict resolution. Fasth proposed two conflict indexes to indicate the level of conflict within a stakeholder group or between two stakeholder groups [11]. Conflict in this chapter is understood to be when the difference between the implementation value of service VQC indicators after multiparty collaboration and the original expectation value of participants exceeds a certain threshold. Due to the vagueness of participants’ decision-making processes, modeling the service VQC indicators as fuzzy interval numbers is more aligned with reality than using standard real numbers [12, 13]. We use ternary interval numbers to define the value range and distribution characteristics of the service indicators. In the context of a crossover service, there are various dependencies on service VQC among multiple stakeholders. As shown in Fig. 9, the global service depends on the local service VQC and impacts the value of local services. Because the service VQC is ultimately quantified by an evaluation indicator, this section does not distinguish between service value, quality, and capability, which are collectively referred to as indicators; they are also referred to as nodes in the multistakeholder service VQC dependency network. However, some indicators that are of

Fig. 9 Multistakeholder VQC dependency network in a crossover service

164

M. Li et al.

high concern to stakeholders, named objective indicators/nodes, are further divided into global objective indicators (GONs) and local objective indicators (LONs). In addition, some indicators, named local basic indicators or leaf nodes (LLNs), do not have internal or external dependencies and can be used to quantify service capabilities. Based on these quantitative relationships, the implementation value of each nonleaf indicator is calculated by traversing upwards according to the values of the leaf nodes. The gap between the implementation and expectation values is an important basis for judging conflicts. Conflicts in this section are divided into three categories according to different mutual exclusions: local conflicts in the participant (LPs), local conflicts among stakeholders, and global conflicts in the overall service (GCs). Traditional QoS optimization methods consider an indicator to be an accurate real number and search for the optimal solutions in the real number domain. However, when service modelers define nonfunctional attributes, it is difficult to measure the indicator as a precise value. Furthermore, the probability distribution of an indicator in a certain interval is not uniform. This section represents the value range and probability distribution of each indicator with ternary interval numbers. Definition 1 For each indicator A, [A]|q=1/0 = (a− , a* , a+ ), a− < a* < a+ represents its value range, where a− is the lower bound and a+ is the upper bound. a* is the most likely value, which may be the mode, median or mean. q represents the superior direction, for a profit indicator, the larger the value, the better, and q = 1; for a cost indicator, the larger the value, the worse, and q = 0. Definition 2 Indicator A has a specific probability distribution function F(x) and a probability density function f(x) within [a− , a+ ]. Additionally, a + f (x) = 1, a−

f max (x) = f (x = a ∗ ), x F(x) = f (x).

(1)

a−

To simplify the calculation, this section uses a triangular distribution function: ⎧ − ⎪ ⎪ 0, x < a ⎪ ⎪ ⎪ ⎪ (x − a − )2 ⎪ ⎪ , a− ≤ x ≤ a∗ ⎨ + (a − a − )(a ∗ − a − ) F(x) = . ⎪ (x − a + )2 ⎪ ∗ + ⎪ , a (a− + a+ )/2, then the indicator distribution is right-skewed; otherwise, it is left-skewed. The conflict measure is calculated according to the similarity and relative advantage between the implementation and expectation values. Definition 3 Suppose the implementation value of indicator A is Aq = (a− , a* , a+ ) and the expectation value is Bq = (b− , b* , b+ ). The probability distribution function of A is F(x) and the probability density function is f(x). The probability distribution function of B is G(x) and the probability density function is g(x). To measure the similarity of these two indicators, the probability of a random variable reaching the intersection of two intervals is calculated as.

Sa,b

⎧ 0, b+ ≤ a − or a + ≤ b− ⎪ ⎪ ⎪ ⎪ (|G(b∗ ) − G(a ∗ )| + |F(b∗ ) − F(a ∗ )|) − ⎪ ⎪ ⎪ , a = b− and a + = b+ 1 − ⎪ ⎪ 2 ⎪ ⎨ + − − − + + . = F(b )G(a ), b ≤ a ≤ b ≤ a ⎪ + − − − + + ⎪ G(a ) − G(a ), b ≤ a < a ≤ b ⎪ ⎪ ⎪ ⎪ ⎪ F(b+ ) − F(b− ), a − ≤ b− < b+ ≤ a + ⎪ ⎪ ⎪ ⎩ F(b− )G(a + ), a − ≤ b− < a + ≤ b+ (3)

Definition 4 The advantage of the implementation value over the expectation value is quantified as the indicator’s relative advantage. If q = 1, then the relative advantage is the probability that the implementation value is greater than the expectation value, P(A > B). If q = 0, then the relative advantage is P(A < B). Additionally, P(A > B) + P(A < B) = 1. For q = 1, the formula for calculating the relative advantage is Eq. 4.

Advq=1 =

⎧ 1, b+ ≤ a − ⎪ ⎪ ⎪ ( ) ⎪ ⎪ ⎪ ⎪ F(b+ )G(a − ) ⎪ ⎪ max 1 − , 0.5 , b− ≤ a − < b+ ≤ a + ⎪ ⎪ 2 ⎪ ⎪ ⎪ ⎪ ) ( ⎪ ⎪ ⎪ G(a − ) − G(a + ) ⎪ ⎪ , 0.5 , b− ≤ a − < a + ≤ b+ max 1 + ⎪ ⎪ 2 ⎪ ⎪ ⎪ ⎪ ⎪ a ∗ − b∗ ⎪ ⎪ ⎪ 0.5 + (F(a ∗ ) − F(b∗ ) + G(a ∗ ) − G(b∗ )), a − = b− and a + = b+ and b∗ < a ∗ ⎪ ⎪ 2(a + − a − ) ⎪ ⎨

. 0.5, a − = b− and a + = b+ and b∗ = a ∗ ⎪ ⎪ ⎪ ∗ − a∗ ⎪ b ⎪ ⎪ (F(b∗ ) − F(a ∗ ) + G(b∗ ) − G(a ∗ )), a − = b− and a + = b+ and a ∗ < b∗ 0.5 − ⎪ ⎪ 2(a + − a − ) ⎪ ⎪ ⎪ ( ) ⎪ ⎪ ⎪ F(b+ ) − F(b− ) ⎪ ⎪ min , 0.5 , a − ≤ b− < b+ ≤ a + ⎪ ⎪ 2 ⎪ ⎪ ⎪ ) ( ⎪ ⎪ ⎪ G(a + )F(b− ) ⎪ ⎪ ⎪ , 0.5 , a − ≤ b− < a + ≤ b+ min ⎪ ⎪ 2 ⎪ ⎪ ⎪ ⎪ ⎩ 1, a + ≤ b−

(4)

166

M. Li et al.

Definition 5 The conflict measure is defined as CS =

(1 − Sa,b )(e − e Adva,b ) . e−1

(5)

where Sa, b represents the similarity with an effective value range is [0, 1]. The greater the similarity, the smaller the conflict. Adva,b represents the relative advantage with an effective value range is [0, 1]. The greater the relative advantage, the smaller the conflict. When the relative advantage is limited to 1, i.e., when the implementation value is completely better than the expectation value, the conflict measure is limited to 0, regardless of similarity. When the similarity is limited to 0, i.e., when there is no intersection between the implementation value and the expectation value, and the relative advantage is also limited to 0, then the conflict measure is the maximum and limited to 1. Definition 6 The node conflict level is calculated as ) ( Disout (node)el Disin (node)ek + . C L node = C Snode · I nd(node) Outd(node) + 1

(6)

where CSnode is the conflict measure of the node. Disin (node) is the longest distance between the node and the local objective nodes, and Disout (node) is the shortest distance between the node and the global objective nodes. Ind(node) is the in-degree of the node, and Outd(node) is the out-degree of the node. k represents the number of conflict nodes in the ancestors of the current node in the local scope, and l represents the number of conflict nodes in the ancestors of the current node in the global scope. Because the impact of conflict propagation is generally exponential, this section takes e as the base of the power function. In this work, conflict resolution and objective optimization are divided into two parts. In the conflict resolution stage, two criteria should be ensured: (1) the lowestlevel conflict nodes in conflict-propagation links are resolved first, and (2) the cost of conflict resolution is evaluated effectively and it is reasonably determined whether the node should retain or resolve the conflict. To this end, this section defines the conflict level calculation as Eq. 6, which determines the resolution order. Figure 10 shows the pseudocode of the algorithm implementation. Conflict resolution continuously adjusts the value range and distribution of basic indicators and then changes the implementation value range and distribution of the objective indicators, indirectly narrowing the gap between the implementation value and expectation value. The cost of conflict resolution is the adjustment range of the basic indicators, which is measured by the similarity (Eq. 3) between the original values of the basic indicators and the values after conflict resolution. The benefit of conflict resolution is the relative advantage of each stakeholder’s objectives, which is measured by the relative advantage (Eq. 4) between the original expectation and the implementation of objective indicators after complex collaboration. The above algorithm avoids high-cost conflict resolution, and the benefits that stakeholders

Crossover Service Optimization: Value and Quality

167

Fig. 10 Pseudocode of conflict-resolution algorithm

obtain from conflict resolution are not considered. The objective optimization algorithm in this subsection balances the costs and benefits of conflict resolution between stakeholders while optimizing the global objectives. First, let the remaining conflict nodes make necessary concessions to reduce the original expectation value. The simplest operation is to set the expectation value of conflict nodes to the implementation value in the minimized conflict resolution, which guarantees that the current total number of conflicts is zero. On this basis, MOEA/D is used to achieve objective optimization. Figure 11 presents the pseudocode of the algorithm. Our work focuses on two points in the optimization process. (1) Global priority principle. We use the traditional MOPSO algorithm and the MOEA/D algorithm to conduct MOO experiments, and the results confirm that a better solution can be

168

M. Li et al.

Fig. 11 Pseudocode of multiobjective optimization algorithm

obtained with the principle of global priority. (2) Local attitudes of multiple stakeholders. While optimizing the global objectives, this section method also evaluates the local optimization and loss of each participant. If the local objectives are not optimized simultaneously, or if the loss is excessive, the stakeholder has an opportunity to express opposition. The weight of each stakeholder to express its attitude depends on its contribution to the global objectives, that is, the adjustment range of the basic indicators. To ensure these two points, this section presents a series of formulas to calculate each stakeholder’s attitude and decision-making power. Definition 6 Suppose that the initial expectation value of an objective indicator is x and its initial implementation value is y. After minimizing conflicts, the expectation value changes to z. In the objective optimization stage, the current value is w. The

Crossover Service Optimization: Value and Quality

169

participants’ attitudes toward the current optimization solution are quantified based on the following four criteria: • y.adv(x) represents, before conflict resolution, the relative advantage of the initial implementation value to the initial expectation value; • z.adv(x) represents, after the conflict node has made a concession, the relative advantage of the expectation value to the initial expectation value; • y.adv(z) represents, after the conflict node has made a concession, the relative advantage of the expectation value to the initial implementation value; • w.adv(z) represents, during objective optimization, the relative advantage of the implementation value to the expectation value after the conflict node makes a concession. Then, the participant attitude is calculated as AT Tgoal N ode = e0.5−z.adv(x) · (w.adv(z) + (λ − y.adv(x) − y.adv(z))).

(7)

where λ ∈ [0, 1] represents the acceptance of participants. The larger λ is, the higher the acceptance, which means that even if local objectives are severely compromised in the optimization process, the result is acceptable. In contrast, if λ is very small, participants are opposed to the optimization result when their own interests are harmed. If a participant has multiple objective indicators, then their attitude is calculated by averaging, maximizing, or minimizing the attitudes toward these indicators. When ATT participant is less than 0, the participant opposes the current optimization plan. Then, the weight of each participant is calculated according to the adjustment range of the leaf nodes.

3 Value/Quality Negotiation and Configuration Optimization Compared with traditional service design, in which design objectives are solely determined by one service provider, the design objectives of a crossover service originate from the convergence of multiple stakeholders of the service. These stakeholders are attached to different business domains and have different value expectations and different service capabilities. There might be implicit conflicts or correlations among these nonfunctional perspectives. In the design of a crossover service, it is necessary to consider all these perspectives and seek a global trade-off between them so that the stakeholders can collaborate effectively to reach the shared goal of the crossover service. In our opinion, the design process of a crossover service is two-fold. First, it is top-down: it transforms the value expectations of all stakeholders of the service into a quality/capability configuration scheme for the service functionalities, activities, and resources of the crossover service. That is, only if the service functionalities,

170

M. Li et al.

activities, and resources reach certain levels of quality and capability can the value expectations of all stakeholders be fully achieved. Second, it is bottom-up: if the capabilities that could actually be offered by these stakeholders are too limited to support the achievement of value expectations, the optimal quality/capability configuration scheme cannot be obtained, so the original value expectations must be adjusted. However, before being able to engage in adjustment in the bottom-up manner, there are many complex details of the top-down process to be understood. The top-down design challenge is accurately and efficiently transforming the value expectations of various stakeholders into a configuration scheme of multiple relevant quality/capability parameters. Owing to a lack of appropriate methods, the current crossover service designers only conduct this transformation artificially, which is difficult to do efficiently. Therefore, to meet this top-down design challenge of a crossover service, we propose a quality and capability design method for crossover services to help designers to identify the optimal configuration scheme by incorporating quality function deployment (QFD). Further, we elaborate on considerations regarding the complex correlations between value expectations and the available capabilities of multiple stakeholders of a crossover service. Because of the constraints of the service quality offered and the resources owned by participants, the designed configuration may not always meet all the value expectations. Therefore, the second optimal configuration solution is to try to negotiate, within the constraints of the capabilities of all parties, to achieve a suboptimal solution that is as close as possible to the initial service target expectations.

3.1 VQD/QCD Two-Stage Configuration QFD is a customer-driven product design method. Chan et al. proposed a systematic approach to QFD with a nine-step model to build the house of quality (HoQ) [14], which is a systematic and operational approach to the QFD process. However, its 1-to-9 scales that could help unify the various measurements in QFD and ninestep process are not suitable to obtain the optimal quality and capability design of crossover services. By incorporating QFD in the requirements development process (RDP) of software systems, QFD can facilitate the design of software systems by transforming user requirements into critical system functions, and then into functional requirements [15]. The QFD-based RDP is proposed for the design of software systems, but is not suitable for the design of crossover service; it also does not handle the subjective and vague information generated by human perceptions and linguistic assessments well. The two-phase framework of VQD-QCD is shown in Fig. 12. The VQD phase supports the design between the value expectations of multiple stakeholders and the GQPs of service functions, and the QCD phase supports the design between the GQPs and LQPs of fine-grained service activities and CPs of service resources. VQD-QCD is the top-down generative design of a quality/capability configuration scheme.

Crossover Service Optimization: Value and Quality

171

Fig. 12 Two-phase framework of VQD-QCD

The input of VQD-QCD includes the following: (1) the functional design of a crossover service, including a business process that consists of a set of activities, a set of resources with specific capability, and the bindings between resources and activities; (2) the value expectations of multiple stakeholders who participate in the crossover service by offering specific resources and who are responsible for executing specific activities, including a set of VIs and their constraints; and (3) the available quality levels of activities and the capability of available resources that each stakeholder can offer to the crossover service. The output of VQD-QCD includes the configuration schemes for (1) GQPs and (2) LQPs and CPs. In the VQD phase, the value expectations on VIs are the input on the left-hand side of the HoQ, and the importance rating of each VI is calculated. At the center of the HoQ, the quantitative relations between the VIs and GQPs of service functions are identified, as well as the way and extent the realization of each VI is affected by GQPs. The importance ratings of the GQPs are calculated and listed in the penultimate row of the HoQ, and the value range of each GQP is calculated using an optimization algorithm and listed at the bottom of the HoQ as the output of VQD, that is, the configuration scheme for GQPs. This is the top-down generative design of GQPs configuration scheme. QCD is similar to VQD, but its objective is to design the configuration scheme for LQPs and CPs. First, the configuration scheme and importance ratings of the GQPs, which are the exact output of VQD, are used as the input to the left-hand side of the HoQ. Second, the quantitative relations between the GQPs of service functions and the LQPs of activities and CPs of resources are identified and input

172

M. Li et al.

Fig. 13 VQD-based design process of the GQPs for crossover service

at the center of the HoQ. Next, the importance ratings of LQPs/CPs are calculated, and then the configuration scheme for LQPs/CPs is obtained as the output of QCD using an optimization algorithm. Figure 13 shows the VQD-based design process of the GQPs, which is used to generate the configuration scheme for GQPs. Step 1. Identify stakeholders and their value expectations First, designers must determine the stakeholders that correspond to the VIs of the crossover service and then gather their value expectations through focus groups and individual interviews. The VIs identified are denoted as VI = {vi1 , vi2 , …, viM }. Stakeholders propose a set of value expectations VP = {vp1 , vp2 , …, vpM } on these value M indicators, where each vpi ∈ VP is vpi = (vii , vii _EV, operatorS). operatorS could be, for example, “>”, “