In the case of proactive approaches for dynamic service composition, situations that may trigger the need for adaptation should be predicted before they lead to faults and failures of the service compositions. As defined in [126], the prediction of faults is concerned with the identification of the occurrence of a fault in the near future based on the assessment of the current state of the system. In the scope of service compositions, the prediction of faults and failures is concerned
with the assessment of the impact of a service, or group of services, misbehaviour, performance degradation, or unavailability in the composition as a whole.
ProAdapt is a proactive adaptation framework consisting of four main steps, namely (i) events monitoring, (ii) analysis and prediction of the events, (iii) deci- sion of actions to be taken due to the events, and (iv) execution of the actions. In order to support these four steps, an architecture was developed for the ProAdapt framework with six main components, namely: (i) Composer, (ii) Execution En- gine, (iii) Adaptor, (iv) Service Discovery, and (v) Event Analyser. An overview of the architecture of the framework is shown in Figure 3.3.
All the components of the framework had to be implemented from scratch due to the lack of support from current technologies. In fact, we were able to extend an existing execution engine to suit our need but only for the first prototype of our framework (see Section 4.1).
In summary, a system administrator specifies some business process and re- lated SLA to be deployed in the execution engine. When clients request these business process through the execution engine, it uses the composer to create an execution instance that is particular to each request. All events produced by the execution engine, such as successful or failed attempts to invoke an operation are reported and analysed by the event analyser. Depending on the context and generated events, the need for adaptation is identified and the adaptor compo- nent updates the running execution instances. Details regarding each of the main components of the framework are described below.
The composer is responsible for parsing business processes descriptions rep- resented in different languages (e.g.; WS-BPEL [115]), and their associated Ser- vice Level Agreements (SLAs), in order to generate the associated Execution
Composer BPD + SLA request Clients Execution Instances Binding Information Composition Template creates Admin specify Execution Engine executes Events generates B in d In fo rm ati o n Re p o si to ry Service Discovery updates Event Analyser monitors Adaptor triggers requires uses generates updates reads updates Web Services refers to reads requests receives
Instances. The current approach is limited to compositions that use stateless ser- vices; i.e.; compositions with service operations that can be replaced at any point during its execution since there is no need to keep track of the interaction-specific data as each subsequent interaction with a stateless service does not depend upon the outcome of the previous interaction.
As explained in Section3.1, the framework considers SLA parameters for the whole composition in order to verify if QoS discrepancies require the need to execute changes in a composition. Therefore, the SLA parameter values will be represented in the internal representation of the business process.
x
Payment Interfacex
Data Checkx
x
Payment Anti Fraud+
In S to ck Out of Stock+
Wrong Data or Fraud
Data/Fraud Check OK Cancel Payment Dispatch Good Payment Received e-Payment Check Stock Cancel Order Payment Canceled
x
O PDF Invoice Web Inform Email Invoicex
O Default Action Email Invoice Selected PDF Invoice Selected Notify CostumerStart End Activity Exclusive OR
x
Parallel+
Inclusive ORO Finish OrderFigure 3.4: Example of a business process for ordering of goods
Figure3.4 presents an example of a business process model using the BPMN notation for ordering goods online. In Figure 3.4, the required operations of the business process are represented as activities. As shown in the example, when a customer makes an order, the system checks the stock and in case of availability of
the required goods, the system displays the interface for executing the payment. In the case of a successful process execution, the payment is received and the goods are dispatched to the customer. Otherwise, both the payment and the order are cancelled. At the end of the business process execution, the customer receives the transaction status from a web interface. In the case of a successful execution, the customer receives an invoice by email or link to PDF file.
There are four different abstract activities or regions defined for Figure 3.4. The Invoke Activity, which is the final level of abstraction before the actual binded service operation, and three logic control regions, namely Parallel, Exclusive OR, and Inclusive OR. The parallel region is self explanatory, each sub-activity within the region will be executed in parallel. For instance, Data Check and Anti Fraud. The distinction between the Exclusive OR and the Inclusive OR is that the last admit more then one path to be executed. While Dispatch Good and Cancel Order will never be executed together, Email Invoice and PDF Invoice may or may not be executed together.
The Execution Engine is the component responsible for running the execution instances. The execution engine receives a request for a particular business pro- cess mapped to a service composition, requests an execution instance from the composer and uses the logic and binding information provided by the execution instance to manipulate input and output parameters.
As explained in the previous section, this work recognises that different private sessions may face distinct circumstances which may temporary and potentially affect only a single session. Moreover, the current state of each session is certainly different, and adaptation procedures may well take into account these different states.
In the framework, when a business process deployed in the execution engine is requested, the associated composition template and default binding information is used to generate an execution model instance of the business process. An execution model instance extends the composition template with information about the (i) execution flow, (ii) deployed endpoint service operations and their locations, (iii) state of a service operation in a composition (e.g., executed, to be executed, and executing), (iv) observed QoS values of a service operation after its execution, (v) expected QoS values of a service operation, and (vii) SLA parameter values for the service operations and the composition as a whole.
x
Payment Interfacex
Data Checkx
x
Payment Anti Fraud+
+
Cancel Payment Dispatch Good Check Stock Cancel Orderx
O InvoicePDF Web Informx
O Activity: CheckStock Provider: LocalProvider WebService: OrderingTools Operation: StockCheck Status: Executed Exp. Rsp. Time: 100 ms Obs. Rsp. Time: 98 ms Cost: 0 p Fidelity: High Reliability: 90% Activity: PaymentInterface Provider: LocalProvider WebService: WebAdmin Operation: DyplayPayInterface Status: Executed Exp. Rsp. Time: 12000 ms Obs. Rsp. Time: 12002 ms Cost: 0 p Fidelity: Very High Reliability: 95% Activity: EmailInvoice Provider: MailServer WebService: POP3Mail Operation: SendEMail Status: To be Executed Exp. Rsp. Time: 250 ms Obs. Rsp. Time: X ms Cost: 0 p Fidelity: Medium High Reliability: 80% ... Activity: DataCheck Provider: StreamLine WebService: CardPayment Operation: SecurityCheck Status: Executing Exp. Rsp. Time: 300 ms Obs. Rsp. Time: X ms Cost: 3 p Fidelity: Very High Reliability: 97%Email Invoice
Process: Online Ordering SLA Maximum Cost: 25 p SLA Maximum Time: 14000 ms Expected Response Time: 13650 ms Expected Cost: 20 p
...
Figure 3.5: Execution model instance for the business process.
Figure 3.5 shows an example of part of an execution model instance for the business process presented in Figure3.4. Figure3.5, shows the deployed endpoint service operations for various activities, the QoS values for the whole execution model instance and for the deployed endpoint service operations, the execution
status of the service operations, and some expected and observed QoS values. As shown in Figure 3.5, the service operations executing the activity of CheckStock and PaymentInterface are offered by the same services provider LocalProvider. The DataCheck activity is offered by service provider StreamLine. The expected cost and response time values for the whole execution model instance are based on the deployed operation endpoints and their status.
The monitor verifies the service operations used in the instantiated execution models and the possible replacement candidates’ operations in other to identify any events that may lead to situations C1, C2 and C4 described in Section 3.1. As shown in Figure 3.3, monitors can either intercept the messages exchanged between the Execution Engine component and the Web Service Operations or check the operations directly, for instance, using online testing. The current im- plementation of the framework focuses only on the first strategy, intercepting calls to the services, observing when new services become available, and checking the QoS values of the operations. It also communicates with the adaptor component to inform about observed events.
The service discovery component identifies possible candidate service opera- tions to be used in the composition, or to be used as replacement operations in case of problems. The work assumes the use of the service discovery approach [130][146] which has been developed to assist with the identification of candidate service operations. This approach advocates a proactive selection of candidate service operations based on distance measurements that match functional, be- havioural, quality, and contextual aspects. The candidate service operations are identified in parallel to the execution of the compositions based on subscribed operations, and are organised in descending order of best matches. The identi-
fied candidates’ operations are used to create and adapt execution models by the adaptor component.
The adaptor together with the Event Analyser are the main components of the framework. Together, they (a) receive events from the execution engine and monitor components (situations C1, C2, and C4), and composer component (sit- uation C3); (b) predict and analyse problems that may exist in the composition based on these events; (c) identify the need for adaptation of the current exe- cution model instances and/or templates; (d) decide on the actions to be taken; (e) makes necessary changes in the execution model instances and/or templates; and (f) informs the execution engine about changes made in the execution model instances.
The decision of actions to be taken and changes in the compositions are made based on the identified events and the list of available replacement candidate service operations identified by the service discovery component. The next section covers the adaptor component in more details.
It is important to note that in out current framework, the monitor is seen as a sub-component of the event analyser, however, an external monitor could be attached to the framework and generate events in parallel, such as new status of service operations.