A Methodology for the Integration of Service Repositories

Abstract

services, considered in the following, are characterized by the following properties: (i) a name; (ii) a set of functional properties; (iii) a set of nonfunctional properties; (iv) a data schema.  Definition 4 (functional properties): functional properties FP(s)={fp1,...,fpn} of a service s define what the service does for the customer. Each fpi in FP(s) enables a change of state of the real world, coherently with the goals expressed by the users in requirements collection. Considering e.g., a service for “Hotel Reservation”, an associated functional property is “reserve a room” In the following, functional properties will be defined through natural language descriptions, in such a way that they can be seen as an extension of the service names.  Definition 5 (non-functional properties): non-functional properties NFP(s)={nfp1,...,nfpm} of a service s define how the service performs the change of state associated with the functional properties. Non-functional properties have been investigated by several authors, such as (O’Sullivan et al., 2005), (Becha & Amyot 2012), and (Zeng et al., 2004) and they concern technical qualities, business terms and legal aspects of the service. Following our example on the “Hotel Reservation”, examples of NFPs are price and payment options. Let’s note that, since we are considering an abstract service, the NFPs do not assume specific values.  Definition 6 (data schema) The data schema describes at a conceptual level, adopting the Entity Relationship model, the portion of real world on which the service operates. An example of data schema for the “Hotel Reservation” service is reported in Figure 2. 7 Communication of the IBIMA _________________________________________________________________________________