Goal-based business service composition

Abstract

As organizations operate under a highly dynamic business world, they can only survive by optimizing their business processes (BPs) and outsourcing complementary functionality to their core business. To this end, they adopt service-orientation as the underlying mechanism enabling BP optimization and evolution. BPs are now seen as business services (BSs) that span organization boundaries and ought to satisfy cross-organizational objectives. As such, various BS design approaches have been proposed. However, these approaches cannot re-use existing business and software services (SSs) to realize the required BS functionality. Moreover, non-functional requirements and their impact on BS design are not considered. This research gap is covered by a novel, goal-oriented method able to discover those BS and SS compositions fulfilling the required BS functional and non-functional goals at both the business and IT level. This method coherently integrates the design steps involved and properly handles the lack of required BS components. It also advances the state-of-the-art in service composition by being able to both select the best composition plan and the best services realizing the plan tasks based on novel plan and service selection criteria.

Appendices

Appendix 1: COP formation for the task-based software service selection problem

The following novel and modified constraints are introduced to the SS selection problem’s COP formation:

$$\begin{aligned}&\begin{array}{l} \mathrm{maximize }(-w_{loss}\cdot loss + w_{cost}\cdot uf_{cost}\left(cost\right)\\ \quad + w_{qos}\cdot qos -w_{num}\cdot num +w_{re-use}\cdot re-use\\ \quad + w_{s-deg}\cdot s-deg) \end{array}\end{aligned}$$

(24)

$$\begin{aligned}&w_{loss} + w_{cost} + w_{qos} + w_{num} + w_{re-use} + w_{s-deg}=1\end{aligned}$$

(25)

$$\begin{aligned}&num=\frac{\sum \nolimits _i c_i\cdot \sum \nolimits _j t_{ij}}{\text{ max}_i\, \sum \nolimits _j t_{ij}}\end{aligned}$$

(26)

$$\begin{aligned}&cost=\sum _i c_i\cdot \sum _j t_{ij}\cdot \sum _k x_{jk}\cdot c_{jk}\end{aligned}$$

(27)

$$\begin{aligned}&loss < 1 \end{aligned}$$

(28)

$$\begin{aligned}&loss=\sum _i c_i\cdot \left(\mathrm max _l\; loss_{il}\right) \end{aligned}$$

(29)

$$\begin{aligned}&loss_{il}=\frac{\sum \nolimits _m loss_{ilm}}{M^{il}} \end{aligned}$$

(30)

$$\begin{aligned}&loss_{ilm}=\sum _{pair\left(o,i\right)\in m.matches} \frac{\text{ iloss}\left(o.msg,i.msg\right)}{\vert m.matches\vert }\end{aligned}$$

(31)

$$\begin{aligned}&inputs_j=\bigcup _{k \text{ s.t} x_{jk}==1} inputs_{jk} \end{aligned}$$

(32)

$$\begin{aligned}&outputs_j=\bigcup _{k \text{ s.t} x_{jk}==1} outputs_{jk} \end{aligned}$$

(33)

$$\begin{aligned}&\forall s,s^{^{\prime }}\in sol,\, s\ne s^{^{\prime }}\rightarrow \lnot excludes\left(s,s^{^{\prime }}\right) \end{aligned}$$

(34)

The analysis of these constraints now follows. Constraint (24) expresses the altered optimization objective, where the term corresponding to the part parameter has been replaced with the term corresponding to the loss parameter. Constraint (25) indicates that the sum of the weights of the optimization criteria must be 1. Constraint (26) computes the num optimization measure by dividing the number of SSs participating in the selected combination with the cardinality of the biggest task combination. Constraint (27) dictates that the value for the cost measure is computed from the sum of the values of the respective cost measures of the SSs of the solution.

Constraints (28)–(33) are used to compute the measure of the overall information loss and to impose a particular limit on its upper value. Constraint (28) indicates that the overall information loss should be less than one so as to guarantee that the selected SS combination will be properly executed. Constraint (29) indicates that the overall information loss is the maximum information loss in the execution paths of the selected task combination. Constraint (30) dictates that the information loss of an execution path is the average information loss of the path’s transitions. Constraint (31) expresses that a transition’s information loss is the average information loss between the messages of its matching parameters [22]. The pairs of matching output–input parameters for each transition are produced and associated with the task combination achieving a particular task functionality by the SS Composer. The last two constraints of the group indicate that the I/O parameters of a task are copied from the respective parameters of the SS selected to realize it.

The final constraint indicates that the proposed solution must not contain any pair of excluding SSs.

Appendix 2: second case study scenario

Suppose that the designer requirements change and the novel Modify Document & Status goal must be achieved, concerning the capability to modify a design document and its status. This goal is attached as an AND sub-goal of Single-Document Evaluation. As no BS achieves this goal and it is obvious that the first method step will return the same BS composition as before, the designer exploits the second method step to realize the missing BS functionality in terms of SSs. The designer dictates that the desired BS must take as input the design document, its information, its new document status, and its modifications (Modifications) and must return the document modification status (DocModStatus) and the modified design document. The designer also specifies that the overall cost should be less than 1 euro, execution time should be less than 2 s, the security should be at the “medium” level, and availability should be greater or equal to 0.7.

Further suppose that the relevant SS (OWL-S and OWL-Q) information was collected in the system repository. Table 5 shows for each SS its name, respective system, I/O concepts, cost, execution time, availability, and security. Note that cost and security information was considered, as first such information is also relevant for the IT level and second no relevant BS exists. It is also obvious that you may not use a SS if you cannot pay for its usage.

Table 5 The functional and service level information of the existing SSs

These SSs can be separated into four groups based on their functionality and exhibited SS level. The first two groups contain SSs that modify a document’s status and construct a document’s name based on its provided information. The document status modification SSs can be separated into those that first search for the document’s meta-data based on the document information and then modify it and those that associate the document name with its metadata so as to retrieve/modify the meta-data based on this name. The last two groups contain SSs that modify a design document based on the given modifications.

The first group relates to a free web-based meta-data management system $(Sys_1)$ having lower performance than the second group’s respective non-free system $(Sys_2)$. The third group relates to a free document modification system $(Sys_3)$ having lower performance than the fourth group’s respective non-free system $(Sys_4)$. Similarly to the reasons constraining BS usage, only a particular system’s respective meaningful SS combinations must be used together as first the meta-data must be stored and managed only at this system and second document naming may be different in each system. So, the SS usage constraints are:

$$\begin{aligned} \left(DN_1,MDW_1\right)\!, \left(DN_2,MDW_2\right) \end{aligned}$$

No usage constraints exist for the last two groups’ SSs, as their SSs’ functionality is independent from that of the other two systems’ SSs.

Based on the available SS information, the task hierarchy shown in Table 6 will be produced. This table depicts for each SS task produced its exact matches and the task combinations realizing its functionality. Only the task corresponding to modifying a document status by also exploiting a naming capability can be produced from the combination of two other tasks: one corresponding to a naming capability, which takes a document’s information and produces its name, and another one that modifies a document status without exploiting a naming capability. Note that there are no subsumption relations between the tasks.

Table 6 The SS task information

The designer requirements are given to the SS composition process, which must find the SS combinations realizing the required BS functionality. First, it produces a task from the functional requirements, which is not equivalent to any other SS task. So, it executes the SS task composition algorithm and produces two task combinations:

$$\begin{aligned} \left(\{T_{MDN},\left(T_{DN}\,;\,T_{MDW}\right)\}\,\Vert \, T_{MD}\right) \end{aligned}$$

The designer inspects them and finds them all relevant. So, he allows the system to proceed with the SS selection based on his non-functional requirements.

Concerning SS selection, a simpler COP may be solved, as all tasks have only exact matches and no SS is re-used for another task, so the s-deg and re-use criteria can be dropped. As there is no information loss between the SSs considered, the loss criterion can also be dropped. Thus, suppose that the designer provides the following weights for the cost, qos, and num criteria: $w_{cost}=0.4,\,w_{qos}=0.4$, and $w_{num}=0.2$, the following quality attribute weights: $w_{exec-time}=0.3,\,w_{avail}=0.3$, and $w_{sec}=0.4$, and the following utility functions for the cost and quality attributes (the security’s utility function is the BS selection one):

$$\begin{aligned}&uf_{cost}\left(c\right)= \left\{ \begin{array}{l} 0.3+\frac{1-c}{1}\cdot 0.7,c\le 1\\ \mathrm max \left(0.3-\frac{c-1}{1}\cdot 0.7,0\right)\!, \quad c>1 \end{array}\right.\\ \\&uf_{exec-time}\left(et\right)= \left\{ \begin{array}{l} 0.3+\frac{2-et}{2-1.5}\cdot 0.7,1.5\le et\le 2\\ \mathrm max \left(0.3-\frac{et-2}{2-1.5}\cdot 0.7,0\right)\!, \quad et>2 \end{array}\right.\\ \\&uf_{avail}\left(av\right)= \left\{ \begin{array}{l} 0.7+\frac{av-0.7}{1-0.7}\cdot 0.3,av\ge 0.7\\ \mathrm max \left(0.7-\frac{0.7-av}{1-0.7}\cdot 0.3,0\right)\!, \quad av<0.7 \end{array}\right. \end{aligned}$$

Then, the COP’s solution corresponds to selecting both the biggest task combination and the free SSs realizing the combination’s tasks, that is, the SS combination:

$$\begin{aligned} \left(\left(DN_1\, ;\, MDW_1\right) \, \Vert \, MD_1\right) \end{aligned}$$

In this case, the SS selection problem does not need to be re-solved for the initial, required BS, as first there is only one solution concerning the missing, leaf BS component, and second this solution will be the last in the execution order. Moreover, the requirements for the missing component can be considered as additional, posed to accommodate for the change incurred in the functional requirements at the business level. Thus, it is assumed that the designer SS level requirements for the remaining BS composition part do not change, so the solution produced will be the same.