Chapter 2 Specifications and Depoyment of SOA Business Appications Within a Configurabe Framework Provided as a Service Adam Grzech, Krzysztof Juszczyszyn, Grzegorz Kołaczek, Jan Kwiatkowski, Janusz Sobecki, Paweł Świ atek and Adam Wasiewski Abstract This chapter presents the concept of deveopment and management of SOA appications within the configurabe service patform which supports a phases starting from business process definition. The unique features of the patform incude: business process compatibiity, easy reconfiguration of composition schemes, visua support for requirements and service definition, QoS assessment (incuding communication services) and service execution contro. Moreover, it iustrates how effective toos for SOA management may be deveoped within the SOA paradigm itsef, and how this paradigm may be used to achieve their interoperabiity and fexibiity. 1 Introduction This chapter is devoted to presenting the main components and functionaities of PaTe (patform for ICT panning and monitoring soutions), an integrated framework supporting business processes in distributed ICT (Information and Communication Technoogies) environment based on the Service Oriented Architecture (SOA) paradigm. The key architectura assumptions of the PaTe are: moduar organization, reconfiguration capabiity, fu compiance with the SOA paradigm. In resut, the users are offered extended capabiities of buiding SOA appications starting from the definition of business processes which are transated to composite services requirements. A components of PaTe are impemented as services which aows to utiize the features of SOA paradigm in patform configuration and management. The framework scope of functionaities is divided into appications that cover the entire ife cyce of business-oriented ICT appications. The framework s appications A. Grzech (B) K. Juszczyszyn G. Kołaczek J. Kwiatkowski J. Sobecki P. Świ atek A. Wasiewski Facuty of Computer Science and Management, Institute of Computer Science, Wrocław University of Technoogy, Wrocaw, Poand e-mai: adam.grzech@pwr.wroc.p S. Ambroszkiewicz et a. (eds.), Advanced SOA Toos and Appications, 7 Studies in Computationa Inteigence 499, DOI: 10.1007/978-3-642-38957-3_2, Springer-Verag Berin Heideberg 2014
8 A. Grzech et a. and toos are responsibe for business requirement anaysis and comparison, service choices or the composition of services, efficient communication and computationa resource provisioning and aocation in a distributed, virtuaized environment as we as for the utiization of resources and the quaity of monitoring and management services. The presented framework covers service request processing, beginning with a service request s arriva unti the competion of the request and evauation of the deivered service. The patform s buiding bocks (modues) assure service request processing, composition of composite services taking into account the functiona and non-functiona requirements, the provision for efficient communication and computationa resources, the execution of services in a virtua distribution environment, and the evauation of the quaity of composite services. A of the aforementioned modues can be appied as independent data processing units or as sequences of such units that support seected sections of the requirements and service-matching processes for any given business process supported by SOA-based or egacy information systems. A the appications within the patform are designed and impemented as open, moduar, scaabe, and heterogeneous components (services) that are integrated according to the SOA paradigm. Such an approach aows for the integration of a or seected appications to support various decision-making processes. So far, we can find many approaches to the probem of business process execution by means of avaiabe software services [25]. In work [26], it is mentioned that, rather than starting with a compete business process definition, the composition system coud begin with a basic set of requirements and in the first step to buid the entire process, whereas many approaches [26] require a we-defined business process to generate such a compex service. Current work often raises the topic of the semantic anaysis of user requirements, service discovery (meeting the functiona requirements), and the seection of specific services against non-functiona requirements (i.e. execution time, processing and communication costs, security, etc.). However, the presented soutions have some disadvantages, i.e. these methods have not yet been successfuy combined to jointy and comprehensivey sove the probem of the composition of compex services that satisfy both functiona and non-functiona requirements. In many cases, ony one aspect is considered. For exampe, the work [57] focuses on the seection of services based ony on one functiona requirement at a time. Other works show that non-functiona requirements are considered to be of key importance; however, many approaches ignore the aspect of buiding a proper compex service structure that is key to the optimization of execution time, for exampe. To date, the service composition probem has been approached from different perspectives. Some have presented speciaized methods for seection services or composite service QoS-based optimization [26]. However, despite the importance of their contribution, those soutions are not widey used. Some propose compete end-to-end composition toos that introduce the concept of a two-stage composition: the ogica composition stage to pare back the set of candidate services and then the generation of an abstract workfow [2]. METEOR-S presents a simiar concept of binding web services to an abstract process and seecting services that fufi the
2 Specifications and Depoyment of SOA Business Appications 9 QoS requirements. Notions of buiding compete composition frameworks are aso cear in SWORD, which was one of the initia attempts to use panning to create web services [47]. However, the proposed approaches are cosed and do not support the impementation of other methods and, because of this, it is difficut to ca them frameworks. Aso, a framework-based approach is what is currenty needed in the SOA fied in order to create composition approaches that are suited to different domains and probems that are characteristic for them. However, the service composition task is ony a partia soution of the depoyment of the SOA business appications probem. Numerous works point out those SOA business appications responsibe for the reaization of business processes shoud be constructed in accordance with business process description techniques [20]. Moreover, they shoud maintain the quaity requirements imposed on the business process reaization by means of composite services. It is especiay important in the event that hardware devices and teecommunication services are invoved. Taking the conditions above into account, the PaTe framework presented in this chapter offers a genera soution for addressing a of the key issues invoved in the depoyment of SOA business appications: a process-eve description of services, service composition, provisioning, dimensioning and execution, service vaidation and security assessment as we as the generation of user interfaces for semanticay described services. A of these features constitute the generic PaTe process for the depoyment of SOA appications (Fig. 1) and are discussed in detai in the foowing sections. It is started with the business process query, compemented by its associated nonfunctiona requirements (cost, security, time constraints, etc.). The query is processed by means of comparing it with existing processes stored in the reposito-ry which contain associated Service Leve Agreements (SLA), defining the requirements for composite services. In the event that there are no adequate processes, a new SLA is created. On the basis of SLA, an SOA appication (composite service) is composed and dimensioned according to its functiona and non-functiona requirements. Composed and dimensioned services are executed by the native PaTe service execution engine environment. The entire process undergoes vaidation and quaity assessment in which the resuts are stored in a repository to be used to process future queries. A stages of the SOA business appication depoyment are performed by dedicated PaTe services that use common repositories. The PaTe framework provides a muti-criteria (functiona and non-functiona) composition of Web services and QoS assurance for utiized ICT services (bez zmian) that aows for the construction of various service seection and composition scenarios. It aso utiizes configurabe composite services to provide for its functionaity. In order to ensure the interoperabiity with externa service and ontoogy repository speciaized services, Mediators, responsibe for database access and providing standardized interfaces for interna PaTe services had been created. As a resut, externa resources can be integrated within the PaTe framework (which was equipped with access contro functions). A of these combined features offer a fexibe and extensibe environment for communication and composition between the components of SOA appications. To the best
10 A. Grzech et a. Fig. 1 Depoyment of SOA business appications within the PaTe framework of our knowedge, it is the first framework for service composition that impements this kind of hoistic and fexibe approach. There are severa unique features of the PaTe framework, associated with the various stages of SOA business appication depoyment: A the key components of the PaTe (namey: service composer, communication mapper, and execution engine) are composite services themseves, which impies that their execution schemes may be easiy reconfigured or extended and a speciaized graphic user interface is provided to support such actions. This approach aows for the creation of repositories of dedicated composite services for the com-
2 Specifications and Depoyment of SOA Business Appications 11 position, mapping, and retrieva of the Web services, which may be used according to current needs. They may be stored and conditionay chosen from the repository. To address the non-functiona requirements of Web services, an extensibe description anguage (SSDL Smart Service Description Language), which aows for the expression of arbitrary non-functiona parameters of a composite service, is proposed. The execution engine interprets the SSDL definitions of composite services and maintains the non-functiona parameters. It has two methods of execution interpretation (the components of a composite service are expicity executed) and composite service emuation (in this case, the execution engine reads the SSDL and communicates ike a service described in the SSDL definition, thus supporting the automatic depoyment of composite services). The framework aso aows the use of externa execution engines (in this scenario, the PaTe engine serves as an SSDL-driven interface for them). The issue of communication between Web services is being addressed by providing a communication mapper a dedicated service which supports a service composer and substitutes each node of the composite service scenario graph with a sub-graph representing the order of the execution of atomic ICT services (communication and computationa) necessary to ink domain atomic services (communication services provide an appropriate medium for the transmission of data between computationa services, whie computationa services are responsibe for data processing tasks such as: encryption, encoding, signa merging/spitting, etc.). The main contribution of this work is at present a nove approach to service seection, composition, and execution, in which the abovementioned functionaities are provided as services. The PaTe framework aows aso the composition of communication services and supports fexibiity via configuration mechanisms for basic processes (composition, mapping, and the execution of services). In the foowing sections the detais of the main activities required to compete a business process query request depicted in Fig. 1 are provided. The next section presents the basics of the business process description in the context of services and proposes an origina PaTe Event-driven Process Contro notation that supports the service-oriented process description and SLA generation. Section 3 covers the composition and provisioning of composite services within the origina architecture, aowing for a fexibe approach to the composition task and the use of various communication and computationa services which are used by the domainoriented services. Section 4 is devoted to the PaTe service execution environment and presents its origina service-based execution engine and scaabe execution environment. The next section discusses service vaidation within the ayered mode of SOA governance aong with a method for composite service security assessment. Finay, Sect. 6 proposes an approach to the automatic generation of user interfaces for semanticay-described composite services.
12 A. Grzech et a. 2 Service-Based Business Processes Description This section is devoted to the presentation of the advantages and disadvantages of we-known and successfuy appied business process modeing attempts and notations in terms of their suitabiity for the simutaneous description of the functiona and non-functiona requirements that are important for composite service composition. Resuts of a critica and comprehensive anaysis of contemporary modeing approaches eads to the specification of invented modeing notation PEPC (PaTe EPC), thus expanding the functionaity of the we-known notations by adding new opportunities required in composite service composition processes. Modes of business processes are used as an input for service composition. A PaTe customer expects a composite service that meets his/her functiona and nonfunctiona requirements. Functiona requirements may be stated as a business process fow or a functiona part of the SLA (Service Leve Agreement). Non-functiona requirements in typica approaches to BPM (ARIS, BPMN) have to be incuded in the SLA. In PEPC, notation for non-functiona requirements can be set for each object in the business process mode. In the first step of the PaTe workfow (Fig. 1), the customer s functiona requirements are compared with the functiona requirements defined for the business process modes avaiabe within the business process repository. Next, the set of known business process modes containing the expected functionaity is compared due to the structura simiarity with the customer s business process. If an acceptabe mode is found in the repository, then the non-functiona requirements are updated. If there is not a suitabe business process mode in the business process repository, then required business processes have to be modeed using tempates (patterns) from the business process repository or beginning with the bank mode (PEPC modeer supports both options). A new business process mode provides information regarding functiona requirements. A customer s non-functiona requirements are added to the SLA (or to the PEPC mode) and PaTe is ready for service composition. 2.1 Business Process Modeing (BPM) Each organization has its own forma or informa rues and patterns of conduct that resut from the experience, knowedge, and competence of empoyees. Usuay taken actions (activities) are arranged in a sequence with ceary-defined start and end triggers, targets, and human or system owners. Such sequences business processes require the invovement of many peope from different organizationa units. This means that the process actors do not have compete vision of the process and knowedge of the actions taken at a process stages. The soution to this probem is business anaysis and then the mapping and modeing of business processes caed Business Process Modeing (BPM). BPM supports standardization of the
2 Specifications and Depoyment of SOA Business Appications 13 management of business processes that pass through mutipe data repositories, appications, departments, or even companies [41]. Business anaysis ets for the understanding of how organizations work to accompish their purposes and defining the capabiities the organization requires to provide products and services to externa stakehoders [1]. On that basis, BPM aows the representation of enterprise processes and the capture of an ordered sequence of business activities and supporting information. Key benefits of BPM are the foowing [21]: formaization of existing processes and spotting needed improvements, faciitation of an automated, efficient process fow, increase of productivity and decrease in the number of empoyees, opportunity for peope to sove the difficut probems. 2.1.1 Basic Rues of BPM Modes of business processes may be designed to answer the question Where are we now ( as-is perspective) or Where do we want to be? ( to-be perspective). The first option gives a common, baseine mode which represents an accurate depiction of the actua situation within the organization. When the mode is deveoped, it may be used to anayze and improve the business process. The second option ends itsef to providing a vision of an organization s deveopment. Such diagrams present how the future processes might appear after incorporating the proposed improvements. Moreover, such modes may be used to demonstrate and simuate the new processes before their impementation. Before starting any business process modeing, it is important to be cear about severa basic questions that can be extended by detaied questions (Tabe 1). Comparing the ARIS methodoogy (especiay EPC diagrams) and BPMN can draw the foowing concusions: ARIS methodoogy enabes a more accurate modeing of an organization s information system, but modeing of the information system requires diagrams from every ARIS perspective, BPMN enabes more a accurate modeing of the process fow, BPMN does not support modeing of the context of business processes, incuding the inkages between the processes. In addition: The ARIS methodoogy is widey-used for business process modeing for the impementation of integrated information systems (in particuar, SAP products for which ARIS offers dedicated diagrams) this means that many organizations (especiay arge and medium size) prepare maps of processes using the ARIS methodoogy during the impementation of the ERP (Enterprise Resource Panning) system,
14 A. Grzech et a. Tabe 1 Questions to answer before business process modeing ARIS (EPC) BPMN Process fow Yes Yes Decision points (connectors, Yes Yes ogica operators) Spitting/merging process fow Yes Yes Sub-processes Yes Yes Process fow incuding activities Yes Yes (functions) and events Different types of events (start, No Yes mid, end) Requirement of mid-events No No Different sub-types of events No Yes (message, exception, timer, etc.) Different sub-types of No Yes activities/functions (human, systems, etc.) Participants and roes in the Yes (bound with Organizationa Yes (as swim anes) process Structure diagram) Difference between process fow No Yes and message fow Miestones No No Exceptions modeing No Yes Definitions of inputs and outputs No No Reationship between processes Yes (Vaue-added diagram) No Reationship between participants Yes (Organizationa Structure No (organizationa units, roes, persons, etc.) diagram) Data structure Yes (ERM Entity Reationship No Mode diagram) Reationship with the environment Yes (Organizationa Structure diagram) Yes (as poos) BPMN seems to be very usefu for documentation of the organization, redesigning of the organization, using knowedge management, and supporting continuous process management, EPC diagrams are easier to understand by those in the organization [34], EPC and BPMN strongy support patterns to reduce the perceived mode s compexity, transforming EPC diagram into the BPMN mode is possibe but with some imitations [22].
2 Specifications and Depoyment of SOA Business Appications 15 2.2 BPM for Service Composition Service composition uses avaiabe services that meet the requirements of a specific user in order to deiver composite services. According to the SOA paradigm, services shoud fufi business needs (in terms of functiona and non-functiona properties). If the business process mode contains the necessary information, it may be the basis for service composition. 2.2.1 Requirements of Service Composition The successfu composition of composite services requires information about the business process, incuding: sequence of activities to be performed (process fow), types of activities, incuding human-centered activities that need human-computer interaction, business ogic (incuding the distribution of the process fow on different paths) functiona and non-functiona requirements, input and output data, the set of services that provide required functionaity (by process, sub-process or activity) this knowedge is avaiabe from the service repository. Tabe 2 shows how the ARIS methodoogy (EPC diagrams) and BPMN meet the needs arising from the composition of composite services. Anaysis of the ARIS methodoogy and BPMN notation shows that their appication for composition of composite services is imited because most of the service composition requirements are not met. Sometimes IT toos or extensions of notations (e.g. for performance measurement [39]) enabes one to sove some probems (e.g. aows the indirect indication of functiona and nonfunctiona requirements Tabe 2 Fufiment of service composition requirements ARIS (EPC) BPMN Sequence of activities (functions) Yes Yes Activity types No Yes (party, as swim anes) Business ogic Yes Yes Definition of functiona No No requirements Definition of non-functiona No No requirements Binding with ontoogy No No Input and output data No No Reationship between activities (functions) and services No No
16 A. Grzech et a. Fig. 2 Meta-mode of PaTe event-driven process contro (PEPC) notation and input/output data), but to get coser to the service composition requirements, expensive commercia toos are needed. To fufi the requirements of business process modeing for composite service composition, the concept of dedicated notation PEPC (PaTe Event-driven Process Contro) was deveoped. PEPC is based on the EPC diagram but has severa extensions that ead to the modeing of business processes as a convenient addition for automated service composition. 2.2.2 PEPC Notation PEPC notation supports business processes modeing that provides modes for the automatic composition and execution; these are used as composite services. The key attributes of the proposed modeing PEPC concept are as foows: (Fig. 2): process fow modeing typica for EPC diagrams (activities are foowed by events, ogica operators AND, OR, XOR and are used simiary to the EPC notation), different graphic objects for system activities (without human-computer interaction) and human activities (with human-computer interaction), connections between activities, events, and ogica operators, names of activities (abes) and key words based on business ontoogy Ş-the functiona properties of activities, activities have defined inputs and outputs based on given data ontoogy, activities and connections have non-functiona properties based on known KPI (Key Performance Indicator) ontoogy,
2 Specifications and Depoyment of SOA Business Appications 17 Fig. 3 Using business ontoogy in PaTe event-driven process contro (PEPC) activities may be added optionay for information (WSDL fie) with the definition of corresponding ICT service or services that provide functionaity required in the activity. PEPC notation uses the concept of Semantic Business Process Modeing (SBPM), a modern Semantic Web approach that adopts we-defined ontoogies in the modes of business processes [11]. PEPC incudes data, business and KPI ontoogies. Data ontoogy stores information about a set of inputs and a set of outputs. Each input and output has a name and type that is necessary in order to ink process activities with services. According to WSDL specifications, each service operation shoud be described by inputs and outputs so it is possibe to find service or services and business process activities that correspond due to inputs and outputs automaticay. Business ontoogy incudes set of terms that describe actions and objects. A combination of those terms is used to set the functiona properties of the activity (Fig. 3). Functiona properties are stored as activity abes or activity key words. KPI ontoogy incudes non-functiona properties of the activities and connections in a hierarchica structure (Fig. 4). Non-functiona attributes of activities and connections aow for the mapping of SLA (Service Leve Agreement) requirements for the business process or any of its components (sub-process, activity, connection). PEPC optionay assigns an atomic or composite service or services to business process activities. It offers the possibiity for one to indicate which services shoud be used in the composition of composite service (e.g. for reasons of safety or signed contracts with the provider of specific services) or precisey define the requirements for such services. Such services shoud be previousy registered in the service repository to ensure the functiona consistency of the composite services. PEPC incorporates the functiona description of the composite services with various QoS indicators thus defining a compete SLA and aowing for service composition and provisioning.
18 A. Grzech et a. Fig. 4 KPI ontoogy for PaTe event-driven process contro (PEPC) 3 Service Composition as a Service On the basis of the SLA that resuts from the business process query, a service composition process begins. To generate a composite service means to find a set of atomic services and bind them together so that they, as a new service, fufi a user functiona and non-functiona requirements. The services stored in repositories are functionay and non-functionay described with terms derived from the ontoogies mentioned in the preceding section. A typicay automated composition process requires a semantic query (description of a required composite service; often this description is referred to as a Service Leve Agreement SLA) and in PaTe consists of two parts: service composition and service mapping. The first is responsibe for the functiona composition of the composite service, whie the second adds the necessary communication services that connect the functionaities whie preserving the QoS defined in the SLA. Recenty, deveoping information and communication technoogies (ICT) have enabed entrepreneurs to deveop monoithic structures into distributed ones. The entrepreneurs coud focus on transating business processes into composite services; thus the Service Oriented Architecture (SOA) becomes a crucia paradigm in designing service-oriented systems (SOS) [65]. In SOS, the key eement is a service that provides certain and we-defined functionaities and is characterized by parameters that describe the quaity of a required and deivered service. Furthermore, services may be instantiated and assembed dynamicay, eading to the changing structure, behavior and ocation of a software appication in runtime. However, to ensure high satisfaction of cients and service
2 Specifications and Depoyment of SOA Business Appications 19 providers profits, the services shoud be provided in order to guarantee a high quaity of service (QoS) [60]. 3.1 Service Description The PaTe approach to the service description probem assumes the use of the native service description anguage, SSDL (Smart Service Description Language), proposed as a soution aowing a simpe description of composite service execution schemes and the support for the functiona and non-functiona description of services there exist simiar soutions, ike ROsWeL anguage, which utiizes a decarative, resource oriented approach [23]. Its functionaity incudes the Web Service Description Language (WSDL) but aso offers important extensions. SSDL is dedicated to service execution support, incuding the service guarantees of QoS parameters and dynamic service composition at runtime. 3.1.1 Languages WSDL appicabiity to service composition Web Service Description Language (WSDL) is a format that aims to describe the functionaity offered by Web services, mainy by describing their interfaces. It provides a machine-readabe description of how to ca Web Services, what parameters to forward, and what to expect from it in return. The WSDL fie describes ony a singe Web Service and its functionaity, whereas SSDL utiizes the WSDL as a base to describe composite services and requirements (or functionaities) of those services. Each SSDL fie that describes a composite service consists of a set of nodes which, connected together in a graph-ike structure, form a composite service execution pan determining a proper way to execute the services and to pass on the data between them. Each SSDL node contains a pointer to a WSDL fie that describes how to access a particuar Web Service in a composite service. The main difference between WSDL and SSDL is not ony the scope of description (atomic service vs. composite service) but aso the fact that WSDL is a compete instruction on how to ca a Web Service via HTTP (namey using SOAP protoco), whie SSDL is an execution pan needing an engine to execute (interpret) it. SSDL When working with the service composition probem, it was noticed that there is a need for a anguage that aows for the definition of requirements and a service execution pan in a unified manner. Composition methods transform user requirements to the form of a composite service that fufis those requirements. The iterature has shown no description anguage designed to utiize this particuar feature. The most widey-known candidates considered were BPEL and OWL-S both designed with different appications in mind. BPEL, a business standard adopted on many occasions, focused on execution of services and has no semantic description
20 A. Grzech et a. of what the services actuay do or shoud do. The atter is especiay essentia for the dynamic composition of semanticay-described services. On the other hand, OWL-S, which offers a semantic description of web services, was designed for the description of atomic services; its offer for composite scenarios whie preserving the non-functiona QoS requirements is imited. A decision was made to design a description anguage that woud have the foowing design notions, have ow compexity, aow for the definition of both functiona and non-functiona requirements of services for composition purposes, and at the same time the designer coud combine the service requirements with specific services. In the process of deveopment of this so-defined anguage, its other aspects became apparent. As a anguage defined for services requirement specifications, it had to aow for the distinction of various we-defined kinds of requirements and services. As a consequence, a speciaized execution engine was designed whose primary purpose was to execute composite services described in such a manner. To fufi the premise of being fuy executabe, the description anguage had to be fuy interpretabe. This interpretation is done in rea-time by composition agorithms invoked by the engine. The designed anguage was named SSDL after its eementary concept of a Smart Service. The idea of Smart Services extends the concept of a composite service. A Smart Service is, in fact, a type of a composite service; however, its eements do not necessariy have to be atomic services. In genera, a Smart Service is an interpretabe and simutaneous definition of atomic services and requirements of different types in one execution pan. At the bottom of a Smart Service definition process stands the foowing usage case. Typicay, users wi want to define and then execute new composite services. In this case, with the use of the provided speciaized graphic user interface (Sect. 6), they wi input their requirements and appropriate composition mechanisms wi be executed to produce an optima composite service. A this can be saved in user profie and executed in we-defined situations when a composed service is requested. However, sometimes a user wi want his orher service to be more fexibe than just a standard composite service. Users can design their composite services to change with time or be composed in rea-time. Saving parts of the Smart Service as requirements and not services wi ead to dynamic interpretation at the point of execution ater. The execution engine, inferring by the type of user requirements, wi be abe to perform different composition scenarios or discover and execute appropriate services for each requirement. Technicay, a Smart Service is represented by a combination of interconnected nodes (Smart Service Graph), some of which can represent concrete services: some sets of services and some various types of requirements. Nodes of a Smart Service are connected by identifying data sources then they define data fow and order of nodes defining contro fow. Various types of nodes can be defined (utimatey in a speciaized ontoogy) as ong as the execution engine is configured to interpret and execute them. Note that it is the user who can define node types and their interpretation of what makes the SSDL anguage dynamic and highy susceptibe to personaization.
2 Specifications and Depoyment of SOA Business Appications 21 A definition of SSDL node types contains a basic data types that aow for the functiona and non-functiona description of a service, its execution requirements, and the description of compex services with the conditiona execution of their atomic components. The SSDL anguage was designed to enabe the description of compex services which is directy interpreted and executed by the service engine as described in Sect. 4.1. SSDL aows a user to define aternatives from which dynamic composition can choose candidate services (in case the base one returns an exception) or introduce more eves of compexity of a service by introducing sub graphs. Furthermore, some contro instructions coud be added to further instruct the execution engine to interpret the Smart Service description. 3.1.2 Functiona and Non-Functiona Service Requirements in SSDL A singe SSDL node, which is used to describe a basic functionaity requirement for a service has severa important sections, which are extensivey used during service seection, composition, and the fina execution pan optimization: Physica description used by every type of data that inks to a specific Web Service, thus representing the optiona description of service execution conditions (requirements eave this section empty), Functiona description used to semanticay describe the capabiities of a service or required capabiities when defining a functionaity-type node Non-functiona description used to describe the non-functiona parameters of a service or requested services such as: time, cost, avaiabiity, etc.; non-functiona parameters that can be requested for composition purposes are not imited in any way externa vaidation can be performed using user-defined ontoogy and rues, for exampe. Each of them is associated with the number of sub-nodes aowing for precise description of a service. Beow, we show an exampe of the information stored within the nonfunctionadescription node: <nonfunctionadescription> <properties> <property> <name>bitrate</name> <vaue>1.5</vaue> <reation>eq</reation> <unit>mb/s</unit> <weight>1</weight> </property> <property> <name>cost</name> <vaue>300</vaue> <reation>t</reation>
22 A. Grzech et a. <unit>pln</unit> <weight>1</weight> </property> </properties> </nonfunctionadescription> This aows the introduction of domain-specific parameters that coud be defined according to the current needs with ony one constraint they shoud be aso represented in the domain ontoogy, which assures the interoperabiity and semantic consistency of our framework. 3.2 Service Composition Methods This section presents a genera composition scenario and introduces the Service Composer as a speciaized service that performs service composition based on the SLA agreement and contains both functiona and non-functiona requirements. The service composer is a configurabe composite service itsef, and therefore offers a fexibe approach in which each of the stages of the composition process may be performed using different methods of service seection and optimization provided as services. This approach can be described as being utiized to ensure efficient service composition and provisioning whie addressing the probem of QoS-aware communication between the components of composite services. 3.2.1 Overview The composition of Web services permits the buiding of compex workfows and appications on the top of the SOA mode [7]. There are two standard approaches to service composition, namey, workfow composition and Artificia Inteigence panning (AI panning). Besides the obvious software and message compatibiity issues, good service composition shoud be carried out with respect to the Quaity of Service (QoS) requirements; these, in turn, can be spit into functiona and non-functiona [26] components. The first are considered to be of key importance; however, preserving the non-functiona requirements (avaiabiity, performance, and security to name ony the most important) is a key factor as we as its importance rapidy grows in distributed environments where compex services are composed of atomic components [25, 33, 40]. 3.2.2 SSDL-Based Service Composition There are two standard approaches to service composition, namey, workfow composition and AI panning. In both approaches, the emphasis is paced on identifying
2 Specifications and Depoyment of SOA Business Appications 23 contro and data fow. Generay speaking, functionaities of a composite service are represented as a Directed Acycic Graph (DAG), aso referred to as a functionaities graph, in which arcs denote interactions among functionaities and nodes determine functionaities (note that a service may be executed periodicay or in a feedback oop this mode is provided by the execution engine described in Sect. 4). Thus, the service composition task can be seen as a determination of a DAG structure, e.g., using AI methods and then a seection of atomic or composite services that provide required functionaities. The service seection is formuated as an optimization task in which an objective function refects QoS attributes aggregation, e.g. response time or price, and constraints concerning structura dependencies in DAG. There are severa known approaches to QoS optimization such as graph-based methods and mathematica programming (integer programming, stochastic programming). Recent trends aso incude semantic modeing and optimization via meta-heuristics, e.g. genetic agorithms. The resut of service composition is a composite service execution graph, which is, simiary to functionaities graph, a DAG, but its nodes are constituted not by functionaities but by services stored in the repositories. In fact, the composite service execution graph shoud have the same structure as the functionaities graph, and its nodes shoud contain services with the functionaity described in the corresponding nodes of the functionaity graph. Composite Services Structure Composition In genera, service composition process consists of two steps. First, the required functionaities and their interactions, i.e., contro and data fow, are identified. Second, for the functionaities graph set, the appropriate candidate services are seected, and as a resut a composite service execution pan is estabished. Candidate services are services that share a specific functionaity defined in the functionaity graph; in other words, they fufi the functiona requirement but are different with respect to the non-functiona properties. Ony one of the candidate services for each functionaity within the functionaity graph wi be seected to repace this functionaity in the composite service execution pan. The service seection is accompished based on non-functiona properties which, generay speaking, can be referred to as Quaity of Service (QoS) attributes: service execution time, service execution cost, service avaiabiity, service execution success rate, service reputation, or service execution frequency. Depending on the structure of the functionaity graph, the non-functiona parameters of the composite service wi be cacuated differenty with respect to the functiona parameter type: i.e., the cost of a composite service is a simpe sum of a services that buid it, whereas service execution time is a sum of the execution times whenever services are executed one after another, and a maximum of those composite service parts where services were executed in parae. For each of the nonfunctiona service parameters, the user paces a constraint, determining the sufficient
24 A. Grzech et a. conditions for the service seection. This defines the goa to seect such services (from sets of candidate services providing a of the requested functionaities) that their aggregated non-functiona parameters constituting the non-functiona composite service parameters meet the user-defined constraints. Service seection consists of severa stages: Inverted service indexing inverted indexing of services, using a domain ontoogy describing the input and output service parameters annotated with service metadata, aowed for faster seection of vaid services, independent of the semantic fiter being used (athough semantic fiters had to be redesigned to fit the approach). Semantic fitering a method for service and requirement comparison that goes through a service requirement consisting of a set of required input and output parameters. Depending on the type of semantic fiter and distance measure used, the method finds concepts that are identica to the requirements or semanticay cose. Note that the definition of semantic coseness depends on the measure being used. Preiminary candidate service sorting at this stage, a set of candidate services that fufi the functiona requirements (seected by semantic fiters) can be sorted using various semantic fiters. More strict or computation-heavy semantic fiters coud be appied to the candidate services sets to estabish how we the functionaities were fufied. Some non-functiona requirements coud be checked ocay at this stage as we. Composite service execution pan generation this stage is defined as an optimization task from which ony one service for each functionaity is seected from sets of candidate services corresponding to nodes in the functionaity graph. This occurs together with other seected services making up the composite service execution pan. Additionay, the inputs and outputs of the services incuded in the pan must be pair-wise compatibe. The agorithm for this stage is the key component to service seection and is described in more detai beow. The service execution pan generation agorithm (Fig. 5) consists of severa steps. First, based on a greedy approach, an initia pan is generated. If the initia pan does not meet the sufficient conditions then its neighbor pan is generated, then the neighbor pan is verified against sufficient conditions. If the neighbor pan is aso not a vaid soution, then it is put onto a taboo ist and the next neighbor pan is generated. This is repeated unti a vaid soution is generated or the agorithm reaches the imit of iterations, which is a standard approach appied for service composition [61]. The taboo ist ensures that the same composite service execution pan wi not be generated repeatedy. Aso, at certain times a simuated anneaing mechanism accepts a neighbor pan that does not meet the requirements so that new soution spaces coud be expored. This is more ikey to happen due to the more iterations performed by the agorithm. The agorithm presented above is a genera heuristic hybrid procedure based on simuated anneaing and tabu search. It triggers more speciaized methods such as the generation of an initia or neighbor service execution pan. Those methods are described beow in more detai.
2 Specifications and Depoyment of SOA Business Appications 25 Fig. 5 Agorithm for service execution pan generation 1. Method for generating composite service initia execution pan The method is a greedy approach in that each functionaity requested by the user seects one service from a set of candidates with the same functionaity. Within each set of candidate services, a service with the highest fitness score is seected. This method does not take into account the structure of the functionaities graph but ocay seects the best candidate service with a requested functionaity. 2. Method for generating oca fitness function The method estabishes a oca fitness function score according to the weighted QoS parameters of each service. The fitness function gives an aggregated, weighted vaue to a QoS parameters of a service, which is normaized reative to other QoS vaues of a candidate services with the functionaity. 3. Method for cacuating the composite service execution pan quaity The method cacuates the quaity of the composite service based on its aggregated QoS parameters compared to the user s non-functiona requirements. The QoS parameters are cacuated based on the composite service execution pan in the aggregation method beow. 4. QoS parameters aggregation method for composite service quaity estimation The method estabishes a vector of QoS parameters for any composite service provided with a composite service execution pan and with QoS parameters for each of atomic services in that pan. The method anayzes the functionaities graph structure: the sequence and parae structures within the service execution pan and generate a vector of formuas for cacuating the QoS parameters for a given functionaities graph. For any composite service execution pan with the structure of the functionaities graph, the generated formuas can be used to quicky estimate its QoS parameters. This is true because the generated formua is based on the functionaities graph and not any particuar composite service execution pan.
26 A. Grzech et a. 5. Neighbor pan generation method This method is based on the simuated anneaing agorithm and, provided with an initia pan and a set of candidate services, finds a neighbor pan that is coser to satisfying the user s requirements. First, a QoS parameters from the previous composite service execution pan (either the initia or previous neighbor pan) that did not satisfy the user requirement are sorted in descending order according to the normaized difference between the QoS parameter and the appropriate requirement. The seected QoS parameters wi be the basis for further modification of the service execution pan. For each of the dissatisfied QoS requirements, the atomic services in the service execution pan are sorted in either descending (if those QoS parameters are service execution time or service execution cost) or ascending (for other QoS parameters such as avaiabiity) order. Repace the first two atomic services from that sorted ist with new services from the appropriate service candidate sets (services with the same functionaity) in such a manner that a newy-seected service is not on the taboo ist for that functionaity; it is a service with the highest fitness function score among the other service candidates for that functionaity. Then, add the seected services to the taboo ists for the appropriate functionaities. The composite service execution pan resuting in those service repacements is a neighbor pan to the previous one with respect to the minor changes made towards repacing the services with the most dissatisfying QoS parameters. As the domain knowedge is represented in the form of ontoogy and the services are semanticay described (in terms of associating their inputs, outputs, and functionaities with the concepts or sets of concepts from the ontoogy), the composition is a process of transforming user requirements defined in the SLA into a fuy-defined composite service that fufis them. In the first stage of the composition process, user requirements are anayzed and assembed into a singe structure that represents a fina composite service structure by a graph where nodes contain user requirements and edges connect those requirements, determining the order in which a fina composite service wi be executed. Then, with the use of knowedge engineering, this structure is enhanced so it defines an execution scenario for particuar atomic services in a composite service. In this stage, no requirement can be eft disconnected from the other requirements. However, the services may differ in non-functiona properties (as in execution time or cost), so in the ast stage for each functiona requirement, a singe atomic service is seected so that a services that buid a composite service jointy fufi the non-functiona requirements. The key feature of the PaTe s service composer is that it is a composite service itsef; each of the components of the composition scheme (SSDL GUI, service matching, and service seection) are performed by the services. PaTe s composition service is described in SSDL and may be freey reconfigured if there are more or better-suited services that coud be used for a specific probem. This approach opens vast possibiities each of the stages coud be performed using different strategies. We may use different semantic discovery methods when searching for services that fufi each of the requirements (or propose different distance measures for concepts in the ontoogy), or various optimization techniques coud be used to produce the
2 Specifications and Depoyment of SOA Business Appications 27 composite service, fufiing the non-functiona requirements, not to mention that a variety of non-functiona parameters coud be requested and optimized by this. Equipped with the above mechanisms, our framework aows composition service designers to incorporate various approaches, test them, and depoy in a form of service enabed composition toos we-suited to different domains and probems. The too consists of two main parts: one is the front end of the appication which aows a business cient to define his/her domain by connecting to externa service and knowedge repositories (here: ontoogies) that wi be used to construct composite services; the second part is the ayer of speciaized services which is extensibe and can provide a variety of services but mainy composition services. The PaTe service composer execution pan may be passed directy to the Execution Engine, but in this work we want to refine our approach even further and introduce the communication (ICT) services, incorporating them to our framework. This is a unique feature of the PaTe which wi be described in detai in the foowing section. Composite Services Provisioning Recenty, enterprises tend to coaborate and integrate their business cores in Web markets in order to maximize both cients satisfaction and their own profits [45]. Therefore, there is an increasing need to deveop methods for combining existing services together to enrich functionaities and decrease execution costs. Hence, the od-fashioned way of deveoping composite services, i.e., human-based service designing, becomes very insufficient due to the enormous number of avaiabe services and a ack of computationa resources. That is why the automatic or semiautomatic service composition method is a crucia eement of any system that impements the service-oriented architecture (SOA) [45]. In genera, service composition process consists of two steps [57]. First, the required functionaities and their interactions, i.e., contro and data fow, are identified. Second, the execution pan is estabished, i.e., for sets of functionaities, an appropriate service version is seected. The service seection is accompished basing on non-functiona properties which, in genera, can be referred to as Quaity-of-Service (QoS) attributes. In most of the proposed approaches for service composition, the domain services are considered apart from information and communication services (ICT services), which are understood as physica means of supporting the execution of domain services [9, 60, 63]. However, in order to aow Service-Oriented Architecture [45] to be appied propery, most of requirements need to be mapped to ICT services. Otherwise, it is ambiguous how the domain services shoud be executed physicay. For exampe, a requirement for a buiding monitoring service consists of the foowing operations: signa acquisition, coding, sending, and decoding. A of these services are, in fact, the ICT services. Thus, the ICT service mapping is a process of mapping requirements to a combination of atomic ICT services which faciitates the deivery of requested domain-specific functionaities. In both approaches, the emphasis is put on identifying contro and data fow. Generay speaking, functionaities of a composite service are represented as a directed acycic graph (DAG) [19, 65, 67] in which arcs