2013 IEEE Seventh International Symposium on Service-Oriented System Engineering

A Survey to Service Composition Methods using Aspects Classification

Yang Syu
Department of Computer Science and Information Engineering National Taipei University of Technology Taipei, Taiwan a29066049@gmail.com

Yong-Yi FanJiang
Department of Computer Science and Information Engineering Fu Jen Catholic University Taipei, Taiwan yyfanj@csie.fju.edu.tw

AbstractAs a promising, few-risk, low-cost, and agile way to rapidly produce and construct executable intended software, in recent years automatic service composition related techniques and methods have been a prevailing and deeply-studied research field, receiving a lot of attentions. For this research field, upon our long-term studies and efforts as well as papers reviewed we present, in this article, a technical profound survey along with the future challenges and directions observed. Before the main body of the survey appears, there are introductions to some vital background knowledge and adopted survey framework, respectively. The framework used in organizing the structure of the survey has been aided and inspired by aspect-oriented paradigm. Keywords- Service-Oriented Architecture; Automatic Service Composition; Semantic Web Service;

I.

INTRODUCTION

In recent years, various software systems become more and more important and indispensable in our daily life, they steadily and strongly sustain the running of our modern society and civilization. Over time, the number of software demands derived from users and the complexity of these demands has been ascending enormously. However, led by some factors like the competitions in businesses, the pressures from customers, and a number of developing limitations (e.g. cost, schedule), adversely the resources available for software development such as budget, time, and people (e.g. architects, programmers) are less and less. Unfortunately, todays software engineers must work with theses disadvantageous conditions and, as a result, that have induced and catalyzed numerous enhancements and improvements on the field of software engineering. To struggle and develop with these detrimental factors and disadvantages, most researchers and practitioners concentrating on software engineering (a studying discipline regarding how to efficiently and properly engineer software) believe that the best way for present-day software development is by means of reusing as much as possible, rather than conventionally programming from scratch. Currently, reusing is a core topic and concept on software engineering and many branching areas of software engineering are mainly around it. Reusing aims on perspectives about how to appropriately and efficiently reuse various artifacts produced previously in order to accelerate development process and enhance products

quality. Today reusing could be happened at several levels: reusing at abstraction (concept) level (e.g. Design and architecture Patterns), reusing at object level (e.g. object classes and methods), reusing at component level (e.g. software product lines, JavaEE), and reusing at system level (e.g. commercial off-the-shelf, COTS) [1]. Besides these, nowadays another general type of software development also relying on the idea of reusing is through service composition under Service-Oriented Architecture (SOA). Creating needed software via service composition currently is quite common in industry and also is a popular and extensively-studied issue in academia, as it is possible, by composing robust ready-made services (service composition), to directly create a required executable service-oriented application system (composite service), without any modification or adaptation to the inner of reused services. Moreover, the process of composition can even be automated, needing not or minimizing human labor force. Generally, the services reused are well-tried reliable components because they already have been used by many other applications (consumers) and are operated as business products (high availability and dependability); in other words, they are dependable enough and have been tested out. Otherwise, since these services probably are offered by external providers, it is entirely unnecessary to worry about the maintenance issue of them. Compare with other reusebased developing approaches, to reused artifacts (services) service composition does not require any extra programming, adaptation, and reconfiguration, which need professional skill and a lot of time, because it belongs to black-box reusing. It is needless to do anything for reused services, such as extending or adapting internal program code of them, which is essential and unavoidable in whitebox reusing approaches. The developers reusing and composing services only rely on services external specifications and descriptions for precisely comprehending their functionalities, behaviors, and non-functional properties. These advantages mentioned and many other benefits, such as lower cost and risk, result in the prevalence of service composition (service-oriented systems) in industry. Furthermore, along with and benefiting from the characteristics aforementioned, it is practicable to even
170

978-0-7695-4944-6/12 $26.00 2012 IEEE DOI 10.1109/SOSE.2013.55

automatically integrate services without and eliminating human intervention (automatic service composition) for the sake of satisfying the requirements that cannot be fulfilled by feeding any single service. The circumstances abovementioned are the primary reasons for why in recent years there are so many researchers and papers concentrating on and putting efforts into automatic service composition as well as relevant research themes. Here we define the scope of research field automatic service composition broadly: diverse automations and auxiliary techniques for the generation and production of executable composite services, so as to widen the view of subsequent survey. In the past, terms like service composition or service selection have been used in different meaning, thus we have re-defined these terms to standardize them, categorize past efforts and, most importantly, for defining our own research concerns (classification). Being able to automatically and agilely create useful and needed software is always so attractive. Since automatic service composition already has been investigated for several years and that has produced hard-to-counted consequences, systematic survey and analysis are doubtless indispensable, valuable and useful, constructing the architecture and overview of the subject (automatic service composition) for people struggling or interesting in the subject to realize, learn, and refer to. Therefore, the primary target and contribution of this paper is to satisfy that demand. As it already has been studied for years and the study is still continuing, thus far automatic service composition is a large-scoped subject involving in several branches and sub-concerns. Researchers focusing on this field can exploit this paper to position their works in the subject (what research concerns are considered and covered by their efforts) and to understand the current overview of the subject. Moreover, through this paper beginners can find their interested areas and learn the subjects outline and basic knowledge, abstractly building a mental cognition model in mind. To have a well-structured survey and exploration, we borrow concept from aspect-oriented paradigm to arrange the surveys organization. We also discuss, before the final conclusion, probable future challenges and directions observed, but a small part of them will be emerged in forms of interleaving with the body of the survey. For completing the missing and weak parts of previous survey article [2], this paper principal is an extension and supplement to it. Contrast with [2], in this version we definitely clarify the survey framework including the reason of adopting it (motivations) as well as its rationale, and hope that the framework can be referred by and useful to other peoples who are doing survey works on different disciplines and subjects holding identical or similar relationships between sub-concerns and knowledge. Consequently, the

framework can be seen as a general paradigm for arranging organization and presentation, which is another primary contribution of this paper. Otherwise, this version include something that are not presented in [2]. Due to the space limitation, some of overlapping contents will be appeared in referral form, pointing to [2]. The rest of this paper is organized as follows. Section II introduces the organizing framework that we used. Section III is about indispensable foundations of service composition as well as knowledge representation. Section IV and V are the kernel of this paper, describing crosscutting and core research concerns of automatic service composition, respectively. Then section VI is about suggestions as well as potential future challenges and directions. Finally section VII presents our conclusion. II. ASPECT-ORIENTED SURVEY FRAMEWORK

In this section, the manner to systematize following text and its rationale will be definitely introduced and explained. A. The architecture of the framework Fig. 1 is an illustration of the framework that we adopted to organize following survey. The bottom of the framework underling all research concerns is the cornerstone of automatic service composition (blue and green rectangles), including two parts: (1) (manual) composition-related things and (2) semantic technology (ontologies). Both of them strongly sustain and enable the possibility of diverse automations. Things upon the cornerstone are the automatic compositions research concerns that we have identified, comprising crosscutting concerns (purple bars) as well as core concerns (yellow bars). The crosscutting concerns include service description, workflow description, and service matchmaking, and the core concerns are service discovery, service classification, as well as service selection and combination (sometimes combination is also called planning, for example, [3]). Other than service discovery, these concerns will all be thoroughly discussed in section IV and V. Although it is a significant early stage during the process of automatic composition, in this paper we do not cover service discovery in detail because most papers reviewed have implicitly assumed that all available services are already known and are, in advance, listed or recorded in certain internal service repositories. In our definition, service discovery is concern with, according to specific requirements, searching for needed services on the Web or external service registries. Nevertheless as remarked in [4], service discovery in essence is intimately correlated with service description and corresponding service matchmaking introduced in section about crosscutting research concerns later. In this manner, the survey work still involves and incorporates the core part of service discovery.

171

Fig. 1.The architecture of survey framework B. Rationale of the framework Below we present the notion implied in the framework. From architectural perspective, the framework can be seen as having two main components: cornerstone as well as research concerns. Each component has two parts, respectively. 1) Cornerstone Thus far, the success of diverse automatic compositionrelated works largely relies on and profits from some basic methods, concepts, and specifications for standardization. To have an insightful and fluent survey, giving preliminary information and explaining fundamental background knowledge for novices, we think that the contents in section III presenting the basis of automatic composition are ignorable and helpful, including two parts. a) Part 1 Since automatic composition is try to remove labor forces, shorten and automate the composition process done by, originally, human service composers for relieving the burden of them, it is inevitably to get involved with techniques or notions implied and used in manual composition. Otherwise, it is also quite important to survey with sufficient background knowledge in mind. Therefore, in this part we succinctly introduce these for filling up the vacancy of the readers and as a beginning of the survey. b) Part 2 Today, employing ontologies modeling valuable and enough domain knowledge to tackle problems is quite common in modern computer science, and ontologies also have been widely applied in automatic composition, empowering and aiding the automation of handcrafted composition. In this part, a brief introduction to ontologies and the applications of them in automatic composition will be described. 2) Research concerns Automatic service composition is a large-scoped academic subject, involving in and profiting from many computer sciences topics (e.g. semantic web, artificial intelligence) and techniques (e.g. AI-planning, ontology) [5]. Otherwise, although the essence of the subject is to automate the production of executable composite service, it is not true that each paper that we have reviewed identically covers all and same area of the subject. In other words, each

paper has its own context assumptions, aiming subproblems, and proposed solution. It is impractical and useless to, for each paper, list and introduce about the subproblems considered and the solution adopted, thus in this paper we present our survey upon the diverse research concerns of the subject. Each concern identified can be seen as a pattern of sub-problem and it is a portion of the subject. For automatic composition problem, in terms of research concerns it is quite difficult to clearly partition the subject into isolated sub-themes (research concerns), as some parts of the subject are tangled and interleaved with one another. With top-down manual composition described in next section in mind (e.g. planning an abstract workflow consisted of abstract activities first, and then selecting a service for each abstract activity to concretize the abstract workflow) [6] [7], some of sub-themes, from the perspective of research concerns, can be seen as horizontally independent. Yet the others cut across them (e.g. the manner for service description). To deal with that and have a systematic and well-structured presentation, the concepts separation of concerns and aspect-oriented principles [8] [1] are employed, definitely identifying crosscutting research concerns and core research concerns. In this way, it is possible to have a systematic view and efficient architecture for our primary purpose mentioned in Introduction. Finally, at the tail of the surveys body, influenced by some emerging trends and cutting-edge research reports, potential solution patterns, future challenges, and research directions are presented and explored. III.
CORNERSTONE

As remarked in section II.B, this section presents the preliminaries and the background knowledge of service composition (part 1), plus a brief introduction to ontologies and the usages of them in composition problem (part 2). A. Part 1 1) Manual Service Composition Process Please referring to the first segment of section II of [2]. 2) Service Types In practical implementations and the works that we have reviewed, doubtlessly most common and typical manner to realize SOA and service composition (both are within the scope of services computing) is Web Services (WSs) technology [5] [9] [10] [5] [11] [12]. In other words, each service is implemented, exposed, and consumed in the form of WS via some standard web protocols (e.g. HTTP, SOAP, and WSDL). The aim of WSs is to make computational and informational resources on the Web universally accessible and interoperable by machine programs. At the early stage, WSs mainly encapsulate and provide computational functionalities or information resources (software services) [13] and are immovably running on heavyweight servers or cloud platforms [14]. But recently the possibility of the type of WSs is enlarged and unlimited. Stimulated by emerging concepts like Internet of Things (IoT) and Everything as a Service (EaaS) and their integration with SOA and service composition [15] [16], more and more physical-world devices have been
172

wrapped and exposed as WS for universal access and control. For example, with concept Sensor as a Service, in [17] they have wrapped diverse types of sensors and home appliances as WSs exposing WSDL interfaces for control, and [16] have mentioned a new concept device-oriented WSs (doWSs), which enable that mobile devices operations can be controlled or used through WS interfaces, making mobile devices as service providers. It is also viable in present-day to run WSs on mobile devices [18] [14]. Furthermore, applying concept Human-Provided Services (HPSs) even human are eligible to become WSs, showing and contributing their capabilities on the Web [19] [20]. Currently the possibility of the types and range of WSs is infinity and innovative. In addition, [12] has pointed out that services are not only restricted to WSs, bus also include some other forms of services like KML-RPC and TCP services. In our opinion, however, concept Everything as a Web Service (EaaWS) is most promising and potential future trend, packing and expressing everything as a WS with universally accessible interface to overcome heterogeneity between things of this world. The infinity of the types of services causes some impacts and future challenges that we will further discuss in section VI. In academia, nevertheless, people principally concern with conceptual services (specifications), rather than services real implementation details. In academia, how services are implemented in reality (e.g. by means of SOAP or Restful WSs [9]) and which form and type of services they are (e.g. doWSs or conventional computing services accessed via TCP) are not so concerned. In most cases, one thing that researchers care about is how services are described at theoretical level, and that will be thoroughly discussed in section IV.A service description later. To conceptual services, a difference in the assumptions of inspected works is the cardinality (called multiplicity in UML) of service-to-operation. In works like [21] (especially in those works that they are concerned with service combination [3] [22] and selection [23] [11] [24] [3] [25] [26] [27] [28] [29]), they have implicitly or explicitly assumed that, for simplicity and concentration, the cardinality of service-to-operation is one-to-one, as the reasons explained in the introduction of [30] as well as the section 4.1 of [31]. Otherwise, although QoS prediction approaches [32] [33] [34] works at service level (one invocation for executing a WS), we think that, according to their text statements, they also view each operation as a single WS for simplicity. To works concerning with service combination and selection, the cardinality is a trivial assumption because, without any substantial influence, they can arbitrarily set service or operation as finest unit or just easily viewing each operation as a single service (e.g. as defined in the section 2 of [35], its workflow is a collection of operations rather than services). However, this assumption largely affects the processing and consequences of efforts belonging to service classification. We will further explain that in section V.A service classification. 3) Requirement specification

Please referring to the third segment of section II of [2]. 4) Outcome of composition Please referring to the fourth segment of section II of [2]. 5) Life Cycle of Composite Service From the viewpoint of CSs, their life cycle goes through design, execution, monitoring, and reengineering phases [30], or more generally, two stages: design-time and runtime. According to our observation and papers reviewed, the majority of automation efforts aim at design-time stage. Here we simply define that the design-time of CSs is period before CSs are started to work and that is triggered by endusers and realized through activating executers (e.g. BPEL engines). With bottom up composition, for instance, the activities involved in this stage may include service discovery, classification, ranking, and service combination (introduced in section V.B). A common feature of these design-time activities is that they are very time-consumed, thus it is impractical and inefficient to do them after receiving invocation requests for CSs from end-users. The runtime are remaining duration until CSs are dropped and are never used again. The activities involved could be the monitoring of non-functional properties of running CSs and runtime adjustment (reengineering). Potential design activities at this stage comprise the rebinding (re-selection) between abstract and concrete services, parameter adaption, and workflow re-planning [24]. Among papers that we reviewed, most papers are aim at design-time issues and only [36] purely focuses on runtime problems. Otherwise, rarely a few works simultaneously cover design-time and runtime issues. For example, [13] concerns with design-time service selection and runtime reselection for better QoS. During the CSs runtime, a necessity is that the processing must be react in real-time, and that is quite difficult to be achieved by most automations since they target on really designing and composing CSs from scratch (e.g. to concretize entire abstract workflow or generate CSs by connecting services one by one). These are hard to be real-time as some tasks, such as doing semantic reasoning on domain ontology, are quite time-consumed. B. Part 2 As mentioned in II.B.1)b), in advance, a crucial element of automatic composition, i.e. ontologies, should be briefly introduced. Ontologies are the backbone of the Semantic Webthe second generation of the Webtrying to share and reuse data (knowledge) across diverse boundaries. The term ontology is originally from philosophy, and in computer and information sciences ontologies are used to model and represent knowledge within specific domain. By capturing concepts implied in applied domain and the relationships between them, ontologies can be used for computers doing logical semantic reasoning. The readers can find more about ontologies in the Introduction of [37], along with exhausted introductions regarding their usage in software engineering.

173

Consider academic researches of automatic composition, we have recognized that, in this field, ontologies have been used in three distinct ways (three usages). In other words, there are three types of knowledge and information represented by ontologies exploited in this field. The first usage of ontologies in automatic composition is to model and encapsulate knowledge within specific domain and this is the most common way that ontologies have been used in the context of computer and information sciences. For ontology example in this usage, [31] [38] have defined a e-healthcare domain ontology representing domain knowledge that their approaches need to solve service combination problem introduced in section V.B). Another common type (usage) of ontologies in this field, called service ontologies, enhances services with syntactic interoperability as semantic services having machineprocessable and readable interfaces. Service ontologies facilitate and enable the possibility of the automation of composition and many other processing of services, such classification and discovery [39] [40], overcoming heterogeneity between service interfaces [41]. We will talk more about service ontologies in section IV.A service description. These two types of ontologies (domain and service ontologies) abovementioned are intimately related to each other. Domain ontologies semantically define terms (concepts) that are specified and referred by an element of a service ontology describing an interface (e.g. input set of a service), they construct and are basis of semantic services [41]. Finally, a relatively rare usage of ontologies is for generating workflows. This type of ontologies encapsulates knowledge regarding business process and section V.B service combination contains more detail about this type of ontologies. As their profound and wide influences to automatic service composition, we consider ontologies as a part of cornerstone of this field and you will find more about their importance and effect after you go through following two sections. IV. CROSSCUTING RESEARCH CONCERNS

As we have explained in section II.B.2), crosscutting concerns cut across core concerns, widely affecting and involving in them. For instance, how services are described and expressed (the concern of service description) extensively influences the rationales of how to match, classify, combine, and select services (another four concerns that we have identified), because service descriptions are the only way to exhaustively realize services. Hence, it is better to present crosscutting concerns prior to core concerns. Below we discuss, in sequence, three crosscutting research concerns: service description, workflow description, and service matchmaking. A. Service Description As remarked at the beginning of this section, concern service description broadly twists with the others. Under SOA, services reusing is black-box, entirely different from many other types of reusing such as component-based

reusing. When reusing components, designers can internally alter and extend reused components by means of reading and modifying their source code (white-box reusing). Through code review and inspection, designers can accurately understand reused components. However, for composition, services external specification is the only means to get the idea of services and that is why this concern vastly cuts across the other and why we present it with top priority. Without pertinent service specifications, all of the things discussed in this paper are unfeasible. As we have discussed in section III.A.2), although there still are many other forms of services like those exemplified in [12], currently the most popular and representative form is, doubtlessly, Web Services (WSs). In addition, motivated by the previously mentioned concepts like Everything as a Web Service (EaaWS), the future tends to wrap everything as a WS for universal access. In this section, therefore, the scope of the forms of services narrows to WSs. Overall, to realize WSs, there are two kinds of descriptions for WSs: 1) descriptions for reading by human and 2) descriptions for machine programs. Furthermore the latter can be further divided into two distinct classes, syntactic and semantic machine-readable descriptions (interfaces). 1) Description for human reading The contents of the WS descriptions for human must be expressed using human-readable nature languages and, in practice, they could be some advertisements on service registries for commenting and selling WSs. As that already mentioned in section III.A.3), the difficulties of nature language processing obstruct the adoption of human languages for automatic composition, causing that the users of an automation have to own or learn professional expertise and that prevents the participation of non-expert end-users. Based on our literature review, only a few works have partially depended on WSs nature language descriptions, such as [41] [42] [43]. 2) Description for machine processing a) Strict Formal Specifications To WS descriptions for machine reading, thus far the most widely-accepted and de-facto standard is Web Service Description Language (WSDL [44]) [41]. But just like the drawbacks stated in the section 2.2 of [10] and the section 4 of [6], WSDL is barely enough to build syntactical interfaces for connecting and invoking WSs. WSDL lacks formal semantic [5] [45] and metadata [10] of services described, hence semantic community has provided service ontologies, such as OWL-S [46], WSMO, and SAWSDL [47] [6], for accurately and semantically depicting WSs. Together with appropriate domain ontology defining the terms within applied domain, they enable and facilitate the automatic manipulation of WSs. b) Conceptual Tuple (Specifications) Both WSDL as well as semantic service ontologies have complex specifications and implementation details, but that are not, in academia, the focus of researchers. For simplicity, researchers in this field usually represent a

174

service in terms of tuple, neglecting trivial specifics. At abstract level, for instance, WSDL simply describes a WS (or its operations) via Input and Output (IO) tuple, namely the SOAP messages intended and produced by the WS. With semantic interfaces, the tuple could be richer including Input, Output, Pre-condition, Effect (IOPE), Capability (C), and Non-functional properties (NF). IOPEC are functional tuple that they together express the functionality of a WS. Non-functional properties are services attributes like QoS. Their detailed definition can refer to [5] [7]. In addition, as mentioned by [48] and its related work, a recent trend QoSaware WSs is widely followed. Thus the semantic specification for services QoS attributes is necessary and already has been proposed. for example, in [48] it has defined a comprehensive ontology scheme for semantically describing classes, QoS, and domain knowledge of services. In our opinion, ontologies defining terms about services non-functional features will be more important in the future when more and more criteria are considered in service selection problem. c) Gap between Formal Specification and Conceptual Tuple and Induced Problems In these tuple, especially in functional tuple, an implicit assumption of most works is that a tuple, e.g. Output of a service, usually comprises only several coordinative simple elements. Each element refers to or is an instance of a concept (class) defined on applied domain ontology. However, in reality, this assumption does not work. In WS interfaces defined by WSDL, each IO element could be a complex SOAP message element having deep and nested structure. A corresponding semantic version of WSDL is SAWSDL [6], it is identical with WSDL in structure and component, with additional semantic annotation for each WSDL component. Despite semantic descriptions for WSs largely benefit automatic composition, they still have several serious problems causing their unreality, as remarked in [22]. One of the problems is that the semantic reasoning on ontology or across plural ontologies is quite time-consumed task. Thus, to each tuple, most works did not assume containing complex and plethoric elements. For instance, in [3] simply the Input element of S8 only has PID and the Output of it is Review. The difference is a gap between academia and industry, resulting in the uselessness and impracticality of academic researches. In order to accelerate semantic-related tasks and enhance the quality of composition, efforts like [22] [31] have proposed using the pre-processing to services as well as specific data structure to store services information in advance. d) Needed Tuple elements It is not true that every proposed approach identically utilize all of the tuple elements abovementioned for its service description format. Which tuple should be included is decided by what are an approachs core concerns. Automations do not need information of services that are not related to the concerns of them. For example, in [27] the authors came up with algorithm to select services for concretizing abstract workflows into workable CSs with intended composite transactional and QoS properties. The

major concern of it is nonfunctional properties of generated CSs and rightly the tuple elements required are the Identity and NF of services. In [25] it focuses on the uncertainty of available time of composed CS and each service is expressed by its name and mobile prediction (timeavailability) information. Both examples concern with nonfunctional aspect dealing with core concern service selection, therefore the functional tuple did not be used in these two cases. Our previous work [7] covers 7-tuple because we need functional and nonfunctional information of services. B. Workflow Description The architecture of most CSs resembles common architecture pattern pipe and filter introduced in the chapter 6 of [1]. Comparatively each CSs component service acts as a filter providing data transformation, and the data (output and input) of component services flow between component services via, for example, the exchanges of SOAP messages (pipes). Most enterprise SOA-based systems also conform to this architecture pattern. Moreover, a workflow (sometimes called business process or orchestration in different contexts, but conceptually they are interchangeable in terms of their essence), which unambiguously indicates the invocation order of component services, usually comprises various types of process structure. These structure types (e.g., sequence, loop, and parallel) are offered for process designers to define workflows and which structure types are available depends on the process language used. Below we separately discuss formal and conceptual workflows, followed by statement regarding a drawback of them and potential solutions. 1) Formal Workflow Definition For defining a workflow of WSs, in both industry and academia currently a widely-adopted standard is Web Service Business Process Execution Language (WS-BPEL) [49]. WS-BPEL totally has more than seven structure types (structured activities) [49] and the readers can refer to the section 2.1 of [50] for a quick understand to it. Besides WSBPEL, there still are many other languages or standards for building and defining workflows, such as BPMN, Petri net [5] [51], YAWL [27], UML activity diagram [21], precedence graph [11], and Mashups [52] [9], these manners have been used in reviewed literature. 2) Conceptual Workflow Definition Analogous with conceptual tuple discussed in section IV.A.2)b), in academia researchers only interest in conceptual logic of workflow rather than generating a real implementation of executable workflow (e.g., a .bpel file that can be executed on a BPEL engine). Therefore, many works like [53] [54] consider and utilize only semantic meaning of top-common structure types (or part of them). These structure types are, presented by BPELs term, sequence, flow, while and if. They have been imported in our previous works [7] [55] and are introduced by most process languages using disparate symbols. For example, in [54], XOR-split as well as XOR-join pair is, in semantic meaning, if, and AND-split as well as AND-join pair equates flow. For more information, an introduction to industrial and

175

formal workflow languages is presented in the section 3 of [5]. 3) Defect of Formal and Conceptual Workflows Although most workflow definition methods originally were not designed for general end-users without professional skills and knowledge, in recent years, however, trend tends to enable end-user to develop services or software wanted by themselves, like concept end-user development (EUD) [12]. Therefore apparently a mutual problem of formal and conceptual workflows is that both forms of workflows are too complicated for nonprofessional end-users. They are not capable of to define intended workflows by themselves, hence the complexity of definition must be done via expert composers, delegating the responsibility of formulating needed workflows from end-users to composers. One of the possible solution types is, rightly, by means of automations creating CSs implying desired workflows automatically, and the end-users do not have to know anything about workflows, they just specify their requirements correctly as we have discussed in section III.A.3)). But a prerequisite of this solution type is that the automatic approach exploited must be able to accept requirements expressed in nature languages, since the approach cannot expect end-users, lacking in professional capability, specifying their requirements in forms of formal specifications, as we already have discussed in section III.A.3). How to create workflows (implied in generated CSs) without any human intervention and effort is the difficulty confronted by service combination (planning) that will be exhaustedly discussed later. Another type of solution devises techniques to enhance end-user-familiar tools for end-users to enact their workflows. For example, in [12], with little revision userfriendly spreadsheet and spreadsheet formula have been employed for specifying workflows to trigger diverse services. In addition, conjunction with workflows created via this sort of solution, approaches discussed in service selection below could be borrowed for optimizing nonfunctional properties of concretized CSs. C. Service Matchmaking In our opinion, probably this is the most important research concern and basis to automatic composition, directly or indirectly associated with other concerns. As before mentioned, in academia, since service tuple are an ideal way for understanding and representing services, service matchmaking is concentrate on the calculations of functional similarity or compatibility between tuple, instead of other services information. We have identified that, for automating composition, in the literature reviewed service matchmaking roughly has two categories, but conceptually they are, in essence, equivalent. These two categories are matchmaking between services (corresponding matchmaking) as well as matchmaking between junctions of services (junction matchmaking). 1) Corresponding Matchmaking More specifically, this category of matchmaking could be calculation between a service and another service,

between a service and an abstract activity, or between a service and a composition request. Essentially, in terms of their specifications, service (sometimes called concrete service), abstract activity (abstract service), and composition request are all identically in concept. Assuming that, in a context that IOPE tuple are adequate and enough to unambiguously describe each service. An abstract activity represents a place that needs a concrete executable service to stuff and satisfy it, thus an abstract activity usually also is described via tuple used for representing each concrete service (in this case, IOPE). As to composition request, in section III.A.3) we already have explained that most efforts conform to query by example principle, simulating a virtual service that is desired. Hence each composition request usually is presented by means of tuple for a service (IOPE in this case) as well. In fact, both abstract activity and composition request represent same thing, a desire to service. The former is desire to concrete single service and the latter is to composite service (CS). A CS consisting of plural component services can be combined and represented by tuple for a single service using integration technique remarked in [7] [56]. Therefore, no matter what are compared (service, activity, or request), all of them can be seen as identical specification having same tuple. The matchmaking is corresponding, e.g. a services Input set is compared and calculated with another services Input set for their degree of likeness or compatibility. Corresponding matchmaking also is a critical concern and essence to other service-related research topics such as service discovery introduced in the section 5.5 of [5] and service retrieve [22], as they must make sure whether services found meet the expectations and requirements. 2) Junction Matchmaking Second matchmaking category is made between services junctions. Junction matchmaking is to calculate between a services Output/Effect and its successor services Input/Pre-condition, trying to clarify whether two services are eligible to be connected together or not. For the sake of simplicity, here an assumption for following text is that dataflow among a CS is stateless instead of stateful assumed in previous work [7] [55], and the following discussion concentrates on Output and Input junction matchmaking. Basically, to figure out if two services are connectable with each other, a question that must be answered and clarified is, whether a services Output set (represented via O tuple) can be link with another services Input set (represented by I tuple). It is to calculate if the elements contained in O tuple are exactly identical or compatible with elements assigned in I set. Thus, actually this category of matchmaking is, in essence, duplicated with corresponding matchmaking that calculates the similarity or compatibility of two identical tuple (e.g. two services Input sets). In addition, junction matchmaking also is an indispensable basis for service combination discussed in section V.B later. 3) The Essence of Matchmaking So far, it has been clearly clarified that corresponding matchmaking and junction matchmaking are equal in

176

essence. In fact, the core and inwardness of them is the comparison of two elements comprised in two distinct service tuple. Below we intently focus on the computation of similarity and compatibility for two elements (terms). In subsection for service description, we already discussed that current research tendency is semantic services, where every service is semantically expressed by pertinent service ontology or conceptual tuple. However, that still is not enough. To be fully semantic and precise, each term appeared on service ontology or in conceptual tuple should be specified and defined on an particular ontology modeling applied domain [29]. Since the design of ontologies and the annotation of terms to services are very time-consuming [22] [35], how to efficiently, precisely, and automatically define terms and ontologies also is another widely followed research issue. For illustration, [22] exploiting a general English words ontology WordNet to specify semantic definitions for semantic-less keywords, and in [35] it has proposed method to automatically generate semantic annotations for operations parameters. Nevertheless, despite it is expensive and costly, currently defining by human experts or designers still is a better and more accurate way. In the next isolated subsection, for the essence of matchmaking, we delineate the reviewed methods in a brief course of improvement from primitive keywords comparison to semantic calculation for terms. a) The reviewed methods in a flow of progressing Most primitive manner like [56] and our previous works [7] [55] base on keywords to define terms (they all focus on junction matchmaking). The likeness calculation of two terms is poorly letter-by-letter string comparison, which is, evidently, far away from accurate, sufficient, and intelligent. More explanation for why keyword is insufficient as well as its drawbacks can refer to the Introduction of [42]. In the literature surveyed, there are many efforts trying to enhance this primitive manner. First, in [42], it has proposed a clustering algorithm for grouping keywords that they are correlated in semantic meaning into same concept and the calculations depend on grouped concepts rather than original keywords. With this solution, obviously it is much better than pure and primitive keyword comparison. But automatically categorized concepts remain not as precise as domain ontologies modeled by domain knowledge experts, as this algorithm cannot identify possible relationships between concepts (e.g. sub-concept). Next, in the first part of [6], it has exploited a general lexical database WordNet to reason semantic relationships and distance (similarity) between two non-semantic keywords. It is capable of to consider and find potential relationships among keywords that [42] cannot do. [47] is analogous with [6], but it further considers relations between terms contained in same theme and adopts a search engine, instead of WordNet, as a basis collecting information to do semantic inference and calculation. It claims that in this way it is better than [6] and [42]. Another work also exploiting WordNet is [22] and it has proposed

formulations for semantic calculation of terms across heterogeneous ontologies. With semantic-annotated terms, the calculations of resemblance and compatibility are more accurate and complex. There are several general relationships between semantic-annotated terms, such as exact match, plugin, subsume, intersection, and disjoint [29]. The place that terms exist absolutely affects the result. For example, in junction matchmaking, an Input including Food is compatible with Output containing Salad or any other sub-concept of Food. Thereby this is a legal connection called causal link (or semantic link) [29] [31] or robust link [3]. However, note that the relationship is not simply symmetric. Explained by a case, an Input including Salad is incompatible with Output containing Food (too abstract). As we discussed in service description, most approaches have implicitly assumed that services IO structures are very simple and that does not match the practical situation in the reality. Only a few approaches like [6] tackling corresponding matchmaking and junction matchmaking and ranking approach in [41] realistically consider complex and nested service structures as well as formal service specifications such as WSDL and text descriptors. Their considerations near more to normal services that we currently use daily. V. CORE RESEARCH CONCERNS

This section is dedicated to three core research concerns that we have identified, containing service classification, combination, and selection. In terms of problem patterns, in fact most automatic composition efforts surveyed can be roughly partitioned into two sorts, trying to figure out a workflow for connecting services (service combination) and trying to choose, for each void activity, a fittest service for concretizing abstract workflow assigned (service selection) [55] [57]. According to our statistic to surveyed papers, about 85 percents of papers are belonging to the latter, and rightly the largest part of this section is third sub-section (entitled service selection), it includes introducing several considered services nonfunctional properties. A. Service Classification Please referring to the section III of [2]. B. Service Combination In our opinion toward automatic composition, concern that is most important and hard to solve is service combination, because it must work out, for each requester, a correct and appropriate skeleton of CS (called workflow or business process) in order to satisfy functional demand asked from requester. In efforts covering service combination, despite these efforts solutions and algorithm details are disparate, roughly there are three distinct combination mechanisms that we observed and extracted from reviewed combination works. First mechanism is that a composer somehow creates abstract non-executable workflow template matching intended functionality, and

177

then concretizing the template by, for example, forwarding the template to approaches concerning with service selection. To second mechanism, a composer directly synthesizes available and known component services as an executable CS implying a needed workflow. Comparatively first mechanism is akin to top-down manual composition earlier mentioned in subsection III.A.1) and second mechanism resembles bottom-up manual composition. As to third mechanism, it is a blend of first and second mechanisms. Below the contents of three subsections discuss and introduce these three mechanisms, respectively. 1) Top-down Automatic Service Combination In manual top-down process, designers receives composition requests and then analyze them, relying on knowledge on workflow design and applied domain (sometimes just like requirement engineering, engineers must work with domain experts as they do not have sufficient domain knowledge). Subsequently based on domain know-how and professional sense, a designer build a procedure to fulfill and gear composition request received. The procedure is a collection of tasks in which every task must be filled and done by something (concrete service). A procedure in designers mind can be written via diverse workflow definition languages mentioned in subsection IV.B. In this way, evidently the key in top-down design is domain knowledge. Therefore, to automate top-down process there must be a knowledge representation model or technique, e.g., ontology, for capturing domain knowledge and facts contained in domain experts mind. The works belonging to first mechanism like [45] leverage knowledge contained and caught in domain ontology to generate pertinent abstract workflow templates. Yet the products are non-executable CS templates, they must further suffer service selection phase in order to become real usable CSs. The biggest barrier of this mechanism is the lack of worth-to-trust domain ontology modeling precise and complete domain knowledge and facts. To overcome the barrier, for instance , [45] devise borrowing well-defined ER-model to construct domain ontology. 2) Bottom-up Automatic Service Combination During bottom-up process, designer definitely knows which services are available and the detailed specifications of them, those are stored in a service repository for access. After receiving a request for CS, designer struggles to filter, pick, and link appropriate services into a viable and reasonable service chain (CS) represented by, for example, WS-BPEL. The linkages between component services depend on dataflow joints, connecting and matching through junction matchmaking introduced in subsection IV.C.2). With this mechanism, workflows are implied in composed CSs and this kind of workflows is called data-driven workflows, because they are constructed by dataflow connections. A formal definition to data-driven workflow is in the section 2 of [35]. According to papers reviewed, most efforts concerning with service combination belong to bottom-up mechanism and this mechanism is more feasible than top-down mechanism. The construction of a domain ontology having

comprehensive and sufficient coverage in applied domain is a great challenge, involving many stakeholders and exertions [22] [45] that obstructs top-down mechanism and decline the workability of it. Another reason that makes the dominance of bottom-up mechanism could be that, contrast to top-down manner, a virtue of it is that the outcome of a composition is a real immediately workable CS rather than a workflow template requiring more handling (selection). To automate handcrafted bottom-up process, many efforts following this mechanism exploit AI planning technique (a introduction to works employing AI planning can refer to the section 3 of [5]), using forward or backward chaining [22] [31]. Complying with bottom-up mechanism, our previous work [7] [55] [56] leverage genetic algorithm to evolve CS. 3) Blend of Top-down and Bottom-up Combinations Third mechanism fuses first and second mechanisms. We have identified the existing of third mechanism from [5], it has proposed a theoretical goal-driven approach adopting top-down mechanism in conjunction with the assistance of bottom-up manner. Unlike most efforts using query by example remarked in subsection III.A.3), in this work composition demands are in forms of well-formulated goal defined through formal goal description language, and required abstract workflows are generated by goal decomposition (top-down mechanism). The decomposition can be based on dedicated goal ontology or domain ontology if they comprehensively and sufficiently describe respective applied domain. However, if they are not good enough to adequately decompose a goal, the composer can discover related real services, acquiring and exploiting their service ontologies (semantic specifications) to aid the decomposition (bottom-up mechanism). Among reviewed combination works, doubtlessly datadriven workflows are the majority because data connections decide the combinability of services and are basis of combination (especially in bottom-up combination), but there still are other types of workflows appeared in reviewed combination works, which are not constructed by junction links. An example is service workflow introduced in [58], it is built with services handling MPEG video stream and each service is described by its capability and state, instead of functional or non-functional tuple. In [58], the combination of example services is quite different from data-driven junction matchmaking combination, in that some services can be arranged at any place among workflow and the others have to be placed before or after certain services. A special type of workflows implied in generated CSs is in our previous work [14] in which combined CSs are without any step-by-step workflow, just trying to aggregate information collected by distributed context-sensing services. Yet presently data-driven workflows remain main trend in business systems. C. Service Selection Giving a workflow template consisted of abstract activities, service selection aims at how to efficiently select an appropriate service for each activity (go through service classification, each activity may have several function178

identical candidate services that they have different nonfunctional characteristics), in order to concretize the template as an executable CS satisfying desired and restricted non-functional criteria. In other words, the intention of service selection is diverse services nonfunctional aspects. In addition, service selection also is a subsequent phase of top-down combination, after top-down combination has successfully created abstract workflows. Service selection could occur during CSs design time, runtime, or both. There are several possible scenarios. The scenario may be that a middleware selects proper service for every activity at design-time, and then rebinding (dynamic binding) inadequate or failed services during runtime, like things done by [13]. Or it is completely dynamic binding at runtime (later binding) without doing any selection at design-time. Dynamic binding is one of the most important advantages promised by original SOA model, but in reality the model does not succeed [10]. The presentation here focus on design-time selection since it is regarding selection for every activity contained in a workflow, instead of merely re-selecting for one or two activities. Normally runtime selection (dynamic binding) only repairs and selects for a workflows segment as it must react in real-time and selection for every activity usually needs longer time. In other words, we concentrate on selection-from-scratch approaches According to our study, thus far for services there are several non-functional aspects (criteria) including Quality of Service (QoS) [26], Transactional Property (TP) [28], reliability [53], mobility prediction [25], quality of semantic link [59], resource consumption as well as distance between services [58], and load-aware with balance [24]. Restrict by the space, below we only present a newly identified nonfunctional properties and for the details of others, please referring to the section III.E of [2]. 1) Causal Link (Semantic link) The concern of causal link is the quality of connections between component services. In the words, it is about, in fact, the overall score of semantic junction matchmaking of CSs. Efforts like [59] [29] concern higher semantic junction quality and QoS level simultaneously and [60] only concentrate on semantic junction quality. D. The Coverage to Core Concerns According to our observation, virtually every research work covers more than one concern because there are crosscutting concerns involving in all of them. For example, [22] concerns with not only service combination but also service description and matchmaking. Another example, [27] mainly focus on service selection, but it still has certain manner to describe services non-functional properties (in this case, QoS and transactional behavior) despite the manner is not the emphasis of this work. Other than crosscutting concerns, there are works trying to cover more than one core concern. For example, our previous work [7] simultaneously concerns with service combination and selection. In [3], it covers all of three core concerns. Nevertheless, upon our observation, most efforts only highlight one core concern. A large part of efforts belonging

to this type is QoS-aware service selection such as [26] [54] [61] [62] [63] [64]. Otherwise, [25] purely concentrates on service selection. VI.
SUGGESTIONS AND FUTURE CHALENGES

At the end of main text, there are some advices and observation results of us. In first part, to top-down and bottom-up composition we suggest, for each of them, an approach pattern in order to give a potential and promising thinking direction about solution design. And then in second part, the aim is to point out possible future research challenges and topics, guiding people in this field to newly unexplored emerging areas. A. Suggestions Please referring to the section IV of [2]. B. Possible Future Challenges and Directions With the advancement of technologies and the appearance of some new concepts, we predict that in the future the types of services being composed and the architecture style of composite services will be quite different from current ones. Traditionally services are mostly running on enterprise servers and are computation-intensive. But, forced by the progression of modern mobile devices, presently these powerful mobile equipments, like smartphones and tablets, certainly are able to act as service providers as well. Advantage and specialty of them are that they can provide many kinds of services that conventional unmovable computing service providers are unable to offer. Services supplied via mobile providers are quite distinct from common computation-intensive services. They could be moving location-based services or environmental contextsensing services gathering immediate real-world data through their sensors equipped. Furthermore, they also can behave as intermediaries for people, enabling them to become movable human provided services [64]. Motivated by facts abovementioned, to define a new model for substituting obsolete triangle SOA model [10] is unavoidable in order to exploit and take advantages of these newly emerging services, as we have mentioned in [14]. It is foreseeable that, in the near future, the things to compose should be mobile services in many cases and thus non-functional aspects uniquely belonging to mobile devices or applications, such as mobility prediction [25], may be the real concern of future mobile service composition, instead of QoS or transaction property that are important concerns to traditional fixed business computing services. Therefore, as we already discussed at the end of previous subsection, identifying and analyzing unknown mobile non-functional aspects are urgent because, in terms of most present-day software end-users, non-functional requirements usually are more important and prior than functional requirements [1]. Otherwise, it is also probably possible that CSs blend conventional as well as mobile services, and in this case the architecture of this sort of CSs may not be typical pipe and filter. Imaginably to deal with that, problems caused by how to define process and

179

aggregate non-functional features are not trivial and should be tackled as soon as possible. VII. CONCLUSION.

On automatic service composition, in a fully-systematic manner this article presents introductory, investigative, and analytical contents for the readers. Compare with other survey works focusing on the same domain, in our opinion this article excels them in the recency, coverage, organization (clarity), and the number of reviewed references. It is confident that the article contributes positive effect to academia and is citable and valuable to disparate readers comprising experts, beginners, and laymen who are interested in the surveyed scope. Except the survey, future possibilities, and some introductions, in this paper we spent comparatively a little more effort on interpreting the rationale of structural framework used for organizing the presentation of our survey, because it is desirous that the proposed aspect-inspired survey framework can also act as a organization and presentation paradigm for other (survey) works on research domains holding analogous structures in knowledge and relationships between concerns to organizing their architectures. ACKNOWLEDGMENT This work is partially sponsored by the National Science Council (Taiwan) under grant NSC 101-2221-E-030-022 and by Fu Jen Catholic University (Taiwan) under grant FJU 410031044044.
REFERENCES
[1] I. Sommerville, Software Engineering, 9/E: Addison-Wesley, 2010. [2] Y. Syu, S.-P. Ma, J.-Y. Kuo, and Y.-Y. FanJiang, "A Survey on Automated Service Composition Methods and Related Techniques," in Services Computing (SCC), 2012 IEEE Ninth International Conference on, 2012, pp. 290-297. [3] F. Wagner, F. Ishikawa, and S. Honiden, "QoS-Aware Automatic Service Composition by Applying Functional Clustering," in Web Services (ICWS), 2011 IEEE International Conference on, 2011, pp. 8996. [4] M. Rambold, H. Kasinger, F. Lautenbacher, and B. Bauer, "Towards Autonomic Service Discovery A Survey and Comparison," in Services Computing, 2009. SCC '09. IEEE International Conference on, 2009, pp. 192-201. [5] D. Zhovtobryukh, "A Petri Net-based Approach for Automated GoalDriven Web Service Composition," Simulation, vol. 83, pp. 33-63, 2007. [6] P. Plebani and B. Pernici, "URBE: Web Service Retrieval Based on Similarity Evaluation," Knowledge and Data Engineering, IEEE Transactions on, vol. 21, pp. 1629-1642, 2009. [7] S. Yang, Y.-Y. FanJiang, J.-Y. Kuo, and S.-P. Ma, "Towards a Genetic Algorithm Approach to Automating Workflow Composition for Web Services with Transactional and QoS-Awareness," in 2011 IEEE World Congress on Services, Washington, DC USA 2011, pp. 295-302. [8] R. Laddad, AspectJ in Action Second Edition: MANNING, 2010. [9] W. Qian and R. Deters, "SOA's Last Mile-Connecting Smartphones to the Service Cloud," in Cloud Computing, 2009. CLOUD '09. IEEE International Conference on, 2009, pp. 80-87. [10] A. Michlmayr, F. Rosenberg, P. Leitner, and S. Dustdar, "End-to-End Support for QoS-Aware Service Selection, Binding, and Mediation in VRESCo," Services Computing, IEEE Transactions on, vol. 3, pp. 193205, 2010. [11] L. Qianhui, W. Xindong, and L. Hoong Chuin, "Optimizing Service Systems Based on Application-Level QoS," Services Computing, IEEE Transactions on, vol. 2, pp. 108-121, 2009.

[12] Z. Obrenovic and D. Gasevic, "End-User Service Computing: Spreadsheets as a Service Composition Tool," Services Computing, IEEE Transactions on, vol. 1, pp. 229-242, 2008. [13] Z. Liangzhao, B. Benatallah, A. H. H. Ngu, M. Dumas, J. Kalagnanam, and H. Chang, "QoS-aware middleware for Web services composition," Software Engineering, IEEE Transactions on, vol. 30, pp. 311-327, 2004. [14] Y. Syu and Y.-Y. FanJiang, "Towards a Participant-Oriented Model to Enhance SOA Model with Mobility," presented at the the World Congress on Engineering and Computer Science 2012, San Francisco, USA, 2012. [15] D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, and D. Savio, "Interacting with the SOA-Based Internet of Things: Discovery, Query, Selection, and On-Demand Provisioning of Web Services," Services Computing, IEEE Transactions on, vol. 3, pp. 223-235, 2010. [16] C. Feng, R. Changrui, D. Jin, W. Qinhua, L. Jinfeng, and S. Bing, "A Comprehensive Device Collaboration Model for Integrating Devices with Web Services under Internet of Things," in Web Services (ICWS), 2011 IEEE International Conference on, 2011, pp. 742-743. [17] M. Nakamura, S. Matsuo, S. Matsumoto, H. Sakamoto, and H. Igaki, "Application Framework for Efficient Development of Sensor as a Service for Home Network System," in Services Computing (SCC), 2011 IEEE International Conference on, 2011, pp. 576-583. [18] R. Mizouni, M. A. Serhani, R. Dssouli, A. Benharref, and I. Taleb, "On the Performance of Hosting Web Services on Mobile Devices," in Services Computing (SCC), 2011 IEEE International Conference on, 2011, pp. 763-764. [19] D. Schall, C. Dorn, H.-L. Truong, and S. Dustdar, "On Supporting the Design of Human-Provided Services in SOA," in Service-Oriented Computing --- ICSOC 2008 Workshops: ICSOC 2008 International Workshops, Sydney, Australia, December 1st, 2008, Revised Selected Papers, ed: Springer-Verlag, 2009, pp. 91-102. [20] D. Schall, H.-L. Truong, and S. Dustdar, "Unifying Human and Software Services in Web-Scale Collaborations," IEEE Internet Computing, vol. 12, pp. 62-68, 2008. [21] M. B. Blake, "Decomposing Composition: Service-Oriented Software Engineers," Software, IEEE, vol. 24, pp. 68-77, 2007. [22] R. Kaijun, X. Nong, and C. Jinjun, "Building Quick Service Query List Using WordNet and Multiple Heterogeneous Ontologies toward More Realistic Service Composition," Services Computing, IEEE Transactions on, vol. 4, pp. 216-229, 2011. [23] H. Wada, J. Suzuki, Y. Yamano, and K. Oba, "E³: A Multiobjective Optimization Framework for SLA-Aware Service Composition," Services Computing, IEEE Transactions on, vol. 5, pp. 358-372, 2012. [24] V. Cardellini, V. Di Valerio, V. Grassi, S. Iannucci, and F. Lo Presti, "A new approach to QoS driven service selection in service oriented architectures," in Service Oriented System Engineering (SOSE), 2011 IEEE 6th International Symposium on, 2011, pp. 102-113. [25] W. Jianping, "Exploiting Mobility Prediction for Dependable Service Composition in Wireless Mobile Ad Hoc Networks," Services Computing, IEEE Transactions on, vol. 4, pp. 44-55, 2011. [26] R. Berbner, M. Spahn, N. Repp, O. Heckmann, and R. Steinmetz, "Heuristics for QoS-aware Web Service Composition," presented at the Proceedings of the IEEE International Conference on Web Services, 2006. [27] J. El Hadad, M. Manouvrier, and M. Rukoz, "TQoS: Transactional and QoS-Aware Selection Algorithm for Automatic Web Service Composition," IEEE Transactions on Services Computing, vol. 3, pp. 73-85, Jan.-March 2010 [28] L. Li, L. Chengfei, and W. Junhu, "Deriving Transactional Properties of CompositeWeb Services," in Web Services, 2007. ICWS 2007. IEEE International Conference on, 2007, pp. 631-638. [29] F. Lecue and N. Mehandjiev, "Towards Scalability of Quality Driven Semantic Web Service Composition," presented at the Proceedings of the 2009 IEEE International Conference on Web Services, 2009. [30] W. Gaaloul, S. Bhiri, and M. Rouached, "Event-Based Design and Runtime Verification of Composite Service Transactional Behavior," Services Computing, IEEE Transactions on, vol. 3, pp. 32-45, 2010. [31] F. Lecue and A. Leger, "Semantic Web Service Composition through a Matchmaking of Domain," presented at the Proceedings of the European Conference on Web Services, 2006.

180

[32] Z. Zheng, H. Ma, M. Lyu, and I. King, "Collaborative Web Service QoS Prediction via Neighborhood Integrated Matrix Factorization," Services Computing, IEEE Transactions on, vol. PP, pp. 1-1, 2012. [33] Z. Yilei, Z. Zibin, and M. R. Lyu, "WSPred: A Time-Aware Personalized QoS Prediction Framework for Web Services," in Software Reliability Engineering (ISSRE), 2011 IEEE 22nd International Symposium on, 2011, pp. 210-219. [34] Z. Zibin, M. Hao, M. R. Lyu, and I. King, "QoS-Aware Web Service Recommendation by Collaborative Filtering," Services Computing, IEEE Transactions on, vol. 4, pp. 140-152, 2011. [35] K. Belhajjame, S. M. Embury, N. W. Paton, R. Stevens, and C. A. Goble, "Automatic annotation of Web services based on workflow definitions," ACM Trans. Web, vol. 2, pp. 1-34, 2008. [36] V. Cardellini, E. Casalicchio, V. Grassi, F. L. Presti, and R. Mirandola, "Qos-driven runtime adaptation of service oriented architectures," presented at the Proceedings of the the 7th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering, Amsterdam, The Netherlands, 2009. [37] Z. Yajing, D. Jing, and P. Tu, "Ontology Classification for SemanticWeb-Based Software Engineering," Services Computing, IEEE Transactions on, vol. 2, pp. 303-317, 2009. [38] F. Lecue and A. Leger "A formal model for Web service composition," presented at the Proceeding of the 2006 conference on Leading the Web in Concurrent Engineering: Next Generation Concurrent Engineering, 2006. [39] S. A. McIlraith, T. C. Son, and Z. Honglei, "Semantic Web services," Intelligent Systems, IEEE, vol. 16, pp. 46-53, 2001. [40] D.Martin, M. Burstein, J. Hobbs, O. Lassila, D.McDermott, S.McIlraith, S. Narayanan, M. Paolucci, B. Parsia, T. Payne, and e. al., "OWL-S: Semantic markup for web services.," 2004. [41] A. Segev and E. Toch, "Context-Based Matching and Ranking of Web Services for Composition," Services Computing, IEEE Transactions on, vol. 2, pp. 210-222, 2009. [42] X. Dong, A. Halevy, J. Madhavan, E. Nemes, and J. Zhang, "Similarity search for web services," presented at the Proceedings of the Thirtieth international conference on Very large data bases - Volume 30, Toronto, Canada, 2004. [43] L. Qianhui, L. Peipei, P. C. K. Hung, and W. Xindong, "Clustering Web Services for Automatic Categorization," in Services Computing, 2009. SCC '09. IEEE International Conference on, 2009, pp. 380-387. [44] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana, "Web Services Description Language (WSDL) 1.1," ed, 2001. [45] X. ChengZhi, L. Peng, W. Taehyung, W. Qi, and P. C. Y. Sheu, "Semantic Web Services Annotation and Composition Based on ER Model," in Sensor Networks, Ubiquitous, and Trustworthy Computing (SUTC), 2010 IEEE International Conference on, 2010, pp. 413-420. [46] M. B. D.Martin, J. Hobbs, O. Lassila, D.McDermott, and S. N. S.McIlraith, M. Paolucci, B. Parsia, T. Payne, et al., OWL-S: Semantic markup for web services: W3C Recommendation, 2004. [47] L. Fangfang, S. Yuliang, Y. Jie, W. Tianhong, and W. Jingzhe, "Measuring Similarity of Web Services Based on WSDL," in Web Services (ICWS), 2010 IEEE International Conference on, 2010, pp. 155-162. [48] A. Moraru, C. Fortuna, B. Fortuna, and R. R. Slavescu, "A hybrid approach to QoS-aware Web Service classification and recommendation," in Intelligent Computer Communication and Processing, 2009. ICCP 2009. IEEE 5th International Conference on, 2009, pp. 343-346. [49] A. Alves, "OASIS Web Services Business Process Execution Language (WSBPEL) v2.0," OASIS Standard 11 April 2007 2007.

[50] L. An, L. Qing, H. Liusheng, and X. Mingjun, "FACTS: A Framework for Fault-Tolerant Composition of Transactional Web Services," Services Computing, IEEE Transactions on, vol. 3, pp. 46-59, 2010. [51] A. Portilla, G. Vargas-Solar, C. Collet, J.-L. Zechinelli-Martini, and L. Garca-Bauelos, "Contract Based Behavior Model for Services Coordination," in Web Information Systems and Technologies. vol. 8, J. Filipe and J. Cordeiro, Eds., ed: Springer Berlin Heidelberg, 2008, pp. 109-123. [52] Sbastien Mosser, Franck Chauvel, Mireille Blay-Fornarino, and Michel Riveill, "Web Services Composition: Mashups Driven Orchestration Definition," presented at the 2008 International Conferences on Computational Intelligence for Modelling, Control and Automation; Intelligent Agents, Web Technologies and Internet Commerce; and Innovation in Software Engineering, , 2008. [53] W. Chien-Min, W. Shun-Te, C. Hsi-Min, and H. Chi-Chang, "A Reliability-Aware Approach for Web Services Execution Planning," in Services, 2007 IEEE Congress on, 2007, pp. 278-283. [54] T. Yu, Y. Zhang, and K.-J. Lin, "Efficient algorithms for Web services selection with end-to-end QoS constraints," ACM Trans. Web, vol. 1, p. 6, 2007. [55] Y.-Y. Fanjiang, Y. Syu, S.-P. Ma, and J.-Y. Kuo, "Transactional web services composition: A genetic algorithm approach," in 2nd International Conference on Software Engineering and Computer Systems, ICSECS 2011, June 27, 2011 - June 29, 2011, Kuantan, Malaysia, 2011, pp. 217-231. [56] L. Aversano, M. D. Penta}, and K. Taneja, "A genetic programming approach to support the design of service compositions," International Journal of Computer Systems Science & Engineering, vol. 21, pp. 247-254, 2006. [57] Y.-Y. FanJiang, S. Yang, W. Chun-Hung, J.-Y. Kuo, and S.-P. Ma, "Genetic algorithm for QoS-aware dynamic web services composition," in Machine Learning and Cybernetics (ICMLC), 2010 International Conference on, 2010, pp. 3246-3251. [58] J. Jin and K. Nahrstedt, "Resource- and quality-aware application-level service multicast," in Distributed Computing Systems, 2003. FTDCS 2003. Proceedings. The Ninth IEEE Workshop on Future Trends of, 2003, pp. 198-204. [59] F. Lecue and N. Mehandjiev, "Seeking Quality of Web Service Composition in a Semantic Dimension," Knowledge and Data Engineering, IEEE Transactions on, vol. PP, pp. 1-1, 2010. [60] F. Lecue, A. Delteil, and A. Leger, "Optimizing Causal Link Based Web Service Composition," presented at the Proceeding of the 2008 conference on ECAI 2008: 18th European Conference on Artificial Intelligence, 2008. [61] G. Canfora, M. D. Penta, R. Esposito, and M. L. Villani, "An approach for QoS-aware service composition based on genetic algorithms," presented at the Proceedings of the 2005 conference on Genetic and evolutionary computation, Washington DC, USA, 2005. [62] D. A. Menasc, A. Casalicchio, and V. Dubey, "A heuristic approach to optimal service selection in service oriented architectures," presented at the Proceedings of the 7th international workshop on Software and performance, Princeton, NJ, USA, 2008. [63] D. A. Menasc, E. Casalicchio, and V. Dubey, "On optimal service selection in Service Oriented Architectures," Perform. Eval., vol. 67, pp. 659-675, 2010. [64] R. G. Daniel Schall, Christoph Dorn, and Schahram Dustdar, "Human Interactions in Dynamic Environments through Mobile Web Services," presented at the IEEE International Conference on Web Services (ICWS 2007), , 2007.

181