2.1 Some definitions

Web service is ‘a software application identified by a URI, whose interfaces and binding are capable of being defined, described, and discovered by XML artifacts, and supports direct interactions with other software applications using XML-based messages via Internet-based applications’ (W3C). A Web service has a functionality that shows the type of ‘service’ it offers to users and peers as well. currencyConversion and carRental are examples of functionalities.

Composition targets users’ requests that cannot be satisfied by any single, available Web service, whereas a composite Web service obtained by combining available Web services may be used. A good number of languages to compose Web services exist, for instance the Web Services Business Process Execution Language (BPEL, defacto standard) and the Web Services Choreography Description Language (WSCDL).

Capacity corresponds to a set of actions to carry out in response to invoking the functionality of a Web service at run-time (Maamar et al., Reference Maamar, Tata, Belaïd and Boukadi2009). A functionality differentiates a Web service from other peers, although it is common that independent bodies develop Web services with similar functionalities but different non-functional properties. Concretely speaking, the actions in a capacity (i) correspond to operations in a WSDL document and (ii) vary according to the business application domain. Some actions in PlaceBookingWS are checkPlaceAvailability and confirmBooking. Several capacities with their respective actions satisfy the unique functionality of a Web service in different ways: which capacity to select and activate out of the available capacities requires assessing the environment so that relevant details about this environment are collected and prepared for this selection. According to the time of the day, GuestWS contacts invitees by either making phone calls in the morning or sending emails in the evening.

Environment assessment identifies the requirements that a Web service needs to satisfy before this Web service first, accepts to participate in a new composition scenario (on top of participating in other ongoing compositions) and second, selects a capacity to trigger after accepting this participation. As a result, environment assessment identifies two types of requirements. Those associated with composition scenarios and those associated with capacity activation. Example of a composition requirement is the maximum number of compositions that a Web service can take part in at a time. And example of a capacity requirement is the minimum network bandwidth to maintain so that a Web service guarantees regular live-content delivery to users of handheld mobile devices.

2.2 Running example

Our running example concerns a university student who organizes a cookout party for his recent graduation. We, hereafter, suggest some Web services that implement this party.

CateringWS searches for and contacts catering companies according to criteria like budget allocated, number of guests expected, and type of cuisine.

GuestWS sends friends invitations, keeps track of invitations confirmed, and reminds guests in case of late confirmations.

PlaceBookingWS looks for a place to host the party, books the place, and completes the necessary paperwork like making down payment to confirm the booking.

WeatherWS checks weather forecast for the day planned of the party. In case of bad weather, the party takes place at the university's function facility. In this paper, WeatherWS illustrates some aspects of our engineering approach. Briefly, WeatherWS accesses a remote database to check out the weather forecast of a city on a certain day and sends users reports. It might happen that the access to the database fails due to network problems or database unavailability.

2.3 Related work on Web services engineering

Our literature review identified a good number of research initiatives that study Web services engineering (Kirda et al., Reference Kirda, Kerer, Kruegel and Kurmanowytsch2003; Robinson, Reference Robinson2003; Chris Gibson, Reference Chris Gibson2004; van Eck & Wieringa, Reference van Eck and Wieringa2004; Jha, Reference Jha2006; Tsai et al., Reference Tsai, Jin, Wang and Wu2007). Unfortunately, none of these initiatives embraces goals as a driving element of the efforts to put into this engineering. Furthermore, our literature review included other initiatives on goal-driven requirement engineering (Donzelli, Reference Donzelli2004; Damas et al., Reference Damas, Lambeau and van Lamsweerde2006; Elghazi, Reference Elghazi2007).

In Chris Gibson (Reference Chris Gibson2004), Chris Gibson stresses the importance of developing a requirement specification for software applications built around Web services. The author reports that deficiencies in software requirements are the leading cause of failure in software projects. The use of Web services to provide B2B online solutions turns out useful; Web services simplify application development and reduce development risk and cost. The requirement engineering process of Chris Gibson is commonly adopted by the IT community with some well-known steps such as elicitation, analysis, modeling and specification, and verification.

In Jha (Reference Jha2006), Jha develops an approach based on problem frames for Web services’ requirements. The approach aligns initiatives on Web services with the strategies of the enterprise so that the objectives, needs, and context of this enterprise are captured. Jha adopts the definition of Zave and Jackson that requirements are all about describing a client's problem domain, determining what desired effects the client wants to exert upon that domain, and specifying the external face of the proposed systems to enable those desired effects to occur and to give designers a specification that guides them in building such systems (Zave & Jackson, Reference Zave and Jackson1997). To capture an enterprise's objective, needs, and context, Jha suggests two steps: understand the enterprise's business strategy and overall objective, and use progression of problems to describe this enterprise's business objective and the business context from strategy to implementation.

In Kirda et al. (Reference Kirda, Kerer, Kruegel and Kurmanowytsch2003), Kirda et al. note that the problem of supporting the automatic integration of Web services into Web sites has received little attention from the research community. To remedy this problem, the authors describe how Web services can be modeled, implemented, composed, and automatically integrated into Web sites using the Device-Independent Web Engineering (DIWE) framework. DIWE promotes the separation between three layers known as layout, content, and application logic.

In Robinson (Reference Robinson2003), Robinson focusses on monitoring the requirements of Web services as part of the process of making software applications reliable. Businesses that embrace Web services as a development technology are automatically vulnerable to the direct shortcomings of these Web services. Addressing these shortcomings before they arise calls for a preventive strategy that Robinson summarizes with the following actions: discover obstacles, assess the derivation of assigned monitors from obstacles, and derive Web service monitors from high-level requirement descriptions. Interesting here is the definition of obstacle, which is an environment condition that prevents requirement satisfaction. Sudden drop in network bandwidth cancels content delivery, unless other alternatives are planned.

In Tsai et al. (Reference Tsai, Jin, Wang and Wu2007), Tsai et al. discuss Service-Oriented System Engineering (SOSE) with focus on Service-Oriented Requirement Engineering (SORE). SORE is different from other traditional requirement engineering approaches since the concerned applications have to comply with the general guidelines of service-oriented architecture. Tsai et al. indicate the following characteristics of SORE: reusability-oriented and cumulative, domain-specific, framework-oriented analysis, model-driven development, evaluation-based, user-centric analysis and specification, and finally, policy-based computing.

In Agre et al. (Reference Agre, Marinova, Pariente and Micsik2006), Agre et al. discuss the engineering of semantic Web services as part of the IST FP6 INFRAWEB project. The use of such Web services is still limited due to different reasons such as complexity of both OWL-S and WSMO. The objective of this project is to develop a semantic service engineering framework to enable the creation, maintenance, and execution of WSMO-based semantic Web services. The potential users of this framework include semantic Web services providers, semantic Web services brokers, semantic Web services application providers, and semantic Web services consumers. In Aoyama et al. (Reference Aoyama, Weerawarana, Maruyama, Szyperski, Sullivan and Lea2002), Aoyama et al. discuss the promises and challenges of Web services engineering. This engineering covers every aspect of a Web service from development, deployment, use, to evolution along with analysis, architectures, development methodologies, descriptions, testing, development environments, management, and applications. Platform, cross-organization boundaries, and business models are among the challenges that Aoyama et al. report.

Last but not least, in van Eck and Wieringa (Reference van Eck and Wieringa2004), van Eck and Wieringa examine the requirements of a specific type of Web services. This specific type of Web services supports other services that, in fact, are not Web services. van Eck and Wieringa use the wording of product experience augmenters to qualify such Web services. In addition, they claim that most Web services in the future will augment existing products or services, rather than constituting an independent economic offering. Some characteristics that feature product-experience-augmenters Web services include: their functional maintenance is the responsibility of the marketing and sales department or the departments that offer the primary product, and they need to properly fit into the business processes.

Although the aforementioned paragraphs offer a reasonable snapshot of the field of Web services engineering, there is no clear vision that articulates how goals could smoothen this engineering. Questions like how to identify and associate goals with Web services, how to review Web services design because of changes in goals, or how to put requirements on Web services are left unanswered and thus, responses are provided on a case-by-case basis.

Prior to concluding this literature review, we mention that capacity-driven Web services fit perfectly into the research stream of non-functional requirements in software engineering (Chung et al., Reference Chung, Nixon, Yu and Mylopoulos1999). By letting Web services select the appropriate operations (in fact, capacities) to execute in response to some requirements, this would allow maintaining a certain level of satisfaction of these non-functional requirements. Different works on service-level agreements in relation to non-functional requirements exist such as Heiko et al. (Reference Heiko, Toshiyuki, Philipp, Oliver and Wolfgang2006) and Oldham et al. (Reference Oldham, Verma, Sheth and Hakimpour2006). These agreements contain clauses on how services are delivered according to different factors like computing resource availabilities, users’ preferences, and network bandwidth. This type of delivery requires mechanisms that guarantee the satisfaction of these clauses at run time. These mechanisms can be implemented through capacities that, as we propose in this paper, are activated after constraint satisfaction. Each time a clause in an agreement needs to be guaranteed, a dedicated capacity is selected. Another initiative that could help specify some elements of capacity-driven Web services is TROPOS (Kazhamiakin et al., Reference Kazhamiakin, Pistore and Roveri2004). Kazhamiakin et al. discuss a framework that combines business processes and business requirements. This framework describes how an organizational strategy is operationalized into activities and implemented by business processes. For business requirement modeling, Kazhamiakin et al. adopt TROPOS, which is a goal-driven, agent-oriented software methodology that covers the complete development cycle of a system. TROPOS can be used to define business requirements and identify them with the corresponding business processes. Applied to capacity-driven Web services, TROPOS could be used to model the requirements to put on these Web services as well as the goals that drive the engineering of these Web services.

3.1 Overview

Figure 1 illustrates our goal-based engineering approach for (component) capacity-driven Web services. This approach can be extended to ‘composite’ Web services at a later stage but this is outside this paper's scope. Basically, our approach sets the goals that would ‘kick-off’ the exercise of engineering a capacity-driven Web service in terms of requirements, capacities, and business logic. The first goal identifies the types of requirements that affect the way the Web service accomplishes its functionality (Section 3.2). The second goal details the capacities that empower the Web service so that this Web service satisfies these requirements (Section 3.3). Finally, the third goal reviews the business logic that underpins the functionality of the Web service following the empowerment of this Web service with capacities (Section 3.4).

Figure 1

Conceptual representation of the goal-based engineering approach

Through our engineering approach for capacity-driven Web services, the three types of goals we suggest can address the following questions:

• Q ₀: What requirements could be posed on a Web service?

  To answer Q ₀, the goals characterize the requirements to put on (i) the data manipulated by a Web service, (ii) the communications means used by a Web service, and (iii) the computing resources upon which a Web service performs (Section 3.2).

• Q ₁: What actions per capacity need to be developed in order to satisfy the requirements defined in Q ₀?

  To answer Q ₁, the goals characterize how to structure capacities in a Web service in terms of actions and input and output arguments (Section 3.3).

• Q ₂: How the business logic of a Web service needs to be adapted because of the capacities defined in Q ₁?

  To answer Q ₂, the goals characterize the changes that are made in a business logic following the weaving of capacities into this business logic (Section 3.4).

3.2 Requirement engineering through goals

In this first step of the engineering approach, the goal analysis contributes towards (i) reflecting the dynamic nature of the environment, (ii) understanding the types of requirements that this environment poses on Web services, and (iii) linking some of these requirements to capacity development. By dynamic nature, we mean Web services appearing and disappearing without prior notice, Web services resuming and suspending operation, sudden drop in network bandwidth, etc. As per the definition of ‘environment assessment’ in Section 2.1, we identify two goals and associate them with ‘composition requirements’ and ‘capacity requirements’, respectively. The former goal regulates the participation of a Web service in a new composition scenario, and the latter goal regulates the activation of at least one capacity in a Web service at run-time.

3.3 Capacity engineering through goals

In this second step of the engineering approach, the goal analysis contributes towards (i) understanding how to structure capacities, (ii) assessing how capacities are triggered, and last but not least (iii) linking these capacities to requirements. As per the definition of ‘capacity’ in Section 2.1, we identify goals with respect to the capacities that empower a Web service. A capacity is a set of operations that a Web service carries out upon receiving requests from users or peers. A Web service could have several capacities that are differently structured according to the functionality it implements and the requirements that these capacities satisfy.

• • $$\[--><$> {\scr O}{\scr P} <$><!--$$ is a set of operations. An operation $$\[--><$> O{{p}_i}\, \in \,{\scr O}{\scr P} <$><!--$$ consists of a name N, a set of input arguments Input along with their data types, and a set of output arguments Output along with their data types, and is written as (N, Input, Output).

• • access is the access modifier of a capacity whether public or private. □

The set of all defined capacities is denoted by $$\[--><$> {\scr C}{\scr A}{\scr P} <$><!--$$ . The rationale of public and private access modifiers is given later.

Example:Let us consider $$\[--><$>{\scr C}{\scr A}{\scr P}_{{PlaceBookingWS}}^{1} <$><!--$$ of PlaceBookingWS. It is specified as follows: ({Op₁, Op₂}, public) where Op₁ = (checkplace, in(date:Date), out(availability:Boolean)), Op₂ = (confirmplace, in(date:Date), out(confirmation:Boolean)), and access is public.

The selection of a capacity in a Web service $$\[--><$> {\scr W}{\scr S} <$><!--$$ for triggering is subject to satisfying some capacity requirements, that is, $$\[--><$> {\scr C}{\scr A}{\scr R}_{{{\scr W}{\scr S}}}^{{i\, = \,1, \ldots, n}} <$><!--$$ . As a result, we define a function that associates a capacity with the capacity requirements as per Definition 4.

The association function Assoc connects each capacity in a Web service $$\[--><$> {\scr W}{\scr S} <$><!--$$ with a set (possibly empty) of capacity requirements ( $$\[--><$> {{2}^{{\scr C}{\scr A}{\scr R}}} <$><!--$$ is the power set of $$\[--><$> {\scr C}{\scr A}{\scr R} <$><!--$$ ). This connection is done manually, that is, designer driven.

Example:Let us continue using $$\[--><$> {\scr C}{\scr A}{\scr P}_{{PlaceBookingWS}}^{1} <$><!--$$ . Assoc $$\[--><$> ( {{\scr C}{\scr A}{\scr P}_{{PlaceBookingWS}}^{1} } )\, = \,\{ {{\scr C}{\scr A}{\scr R}_{{PlaceBookingWS}}^{1} } \} <$><!--$$ where $$\[--><$> {\scr C}{\scr A}{\scr R}_{{PlaceBookingWS}}^{1} <$><!--$$ is defined as follows: $$\[--><$> \lt datafreshness,current, \cdots, null,On{{t}_{req\,{\rm{ - }}\,cap}} \gt <$><!--$$ .

Based on Section 3.3, the following comments are made:

• • A capacity in $$\[--><$> {\scr W}{\scr S} <$><!--$$ , which does not have any requirement to satisfy is referred to as default, that is, $$\[--><$> Assoc({\scr C}{\scr A}{\scr P}_{{{\scr W}{\scr S}}}^{i} )\, = \,\emptyset <$><!--$$ . A default capacity is automatically selected when none of the available capacities in $$\[--><$> {\scr W}{\scr S} <$><!--$$ satisfies the current capacity requirements. By having a default capacity, $$\[--><$> {\scr W}{\scr S} <$><!--$$ can always guarantee the satisfaction of a user's request.

• • Independent capacities in $$\[--><$> {\scr W}{\scr S} <$><!--$$ can have common operations, that is, $$\[--><$> \cap _{{i\, = \,1}}^{n} {\scr C}{\scr A}{\scr P}_{{{\scr W}{\scr S}}}^{i} \, \ne \,\emptyset <$><!--$$ .

• • Common operations in independent capacities can be overloaded if necessary. For example, Op ₁ takes one input argument in $$\[--><$> {\scr C}{\scr A}{\scr P}_{{{\scr W}{\scr S}}}^{1} <$><!--$$ , for example, in(username:String), and two input arguments in $$\[--><$> {\scr C}{\scr A}{\scr P}_{{{\scr W}{\scr S}}}^{n} <$><!--$$ , for example, in(username:String, password:String).

In Section 3.3, a capacity has either public or private access modifier like in object-oriented programming languages (Figure 2)Footnote ³. On the one hand, public capacities are offered to the external environment namely users and other Web services. Submitting invocation messages to public capacities requires fulfilling capacity requirements. On the other hand, private capacities are hidden as their name hints and are just called by public capacities. By doing so, the privacy of a Web service in terms of offered and existing capacities is maintained; only the necessary capacities are exposed. It should be noted that private capacities might call each other if necessary ((0, n) cardinality in Figure 2), but this is not the case with public capacities ((0, 0) cardinality in Figure 2) since they all implement the unique functionality of a Web service.

Figure 2

Capacity categorization

3.4 Business logic engineering through goals

In this third step of the engineering approach, the goal analysis contributes towards (i) understanding the current practices in terms of business processes, (ii) motivating the need of changing these processes, and last but not least (iii) linking these process changes to requirement satisfaction.

As per the definition of ‘Web service functionality’ in Section 2.1, we identify a goal with respect to the functionality (e.g. currencyConversion) of a Web service. A functionality is about a business logic that describes the processes to execute in terms of how, when, and where. A business logic is domain-application dependent (e.g. education, tourism) and varies from one case study to another according to elements such as users (e.g. minimum age to submit an application), security (e.g. maximum length of encrypted key), and legal (e.g. minimum VAT rate).

• • fct is a narrative description of the functionality.

• • bl is a specification of the business logic.

The specification of a business logic uses state charts but other techniques like petri-nets could be used.

• • $$\[--><$> {\scr S} <$><!--$$ is a finite set of state names.

• • $$\[--><$> {{s}^0} \, \in \,{\scr S} <$><!--$$ is the initial state in $$\[--><$> {\scr S}{{{\scr C}}_{{\scr W}{\scr S}}} <$><!--$$ .

• • $$\[--><$> {{{\scr S}}^{\scr F}} \, \subset \,{\scr S} <$><!--$$ is a finite set of final states.

• • $$\[--><$> {\scr L} <$><!--$$ is a set of labels. In state chart, a label consists of an event component E, a condition component C, and an action component A, and is written as E[C]/A. For representation purposes in Figure 3, we just name labels without giving full details of the conditions and actions. In our goal-based engineering approach, condition C is split into pre-condition represented as $$\[--><$> \bullet C <$><!--$$ and post-condition represented as $$\[--><$> C \bullet <$><!--$$ . If state s_i is directly connected to state s_{i + 1}, the post-conditions of s_i subsume the pre-conditions of s_{i + 1}, that is, $$\[--><$> {{s}_i}(C \bullet )\, \Rightarrow \,{{s}_{i\, + \,1}}( \bullet C) <$><!--$$ .

  Figure 3

  Business logic of WeatherWS

  

• • $$\[--><$> {\scr T}\, \subseteq \,({\scr S}\,\times \,{\scr L}\,\times \,{\scr S}) <$><!--$$ is a finite set of transitions. Each transition $$\[--><$> t\, \in \,{\scr T},t\, = \,({{s}^{src}}, l,{{s}^{tgt}} ) <$><!--$$ consists of a source state $$\[--><$> {{s}^{src}} \, \in \,{\scr S} <$><!--$$ , a target state $$\[--><$> {{s}^{tgt}} \, \in \,{\scr S} <$><!--$$ , and a transition label $$\[--><$> l\, \in \,{\scr L} <$><!--$$ . □

Example:Figure 3 is a state chart that represents weatherForecast functionality of WeatherWS. Several states like city-located, report-delivered, and search-canceled are included in this state chart. Moreover, this state chart includes transitions such as (city-located, unavailable, search-canceled) where city-located and search-canceled are the source and target states, respectively, and unavailable is the label of the transition.

The business logic in Figure 3 is an example of how a ‘regular’ (i.e. mono-capacity) Web service (WeatherWS) functions independently of the requirements of type capacity (can be security, network, trust, etc.) that are posed on this Web service, and thus can restrict the functioning of this Web service. Unfortunately, the specification of a business logic is tightened to the functionality to offer and does not show how these capacity requirements are handled nor how this functionality is affected because of these requirements. To address this lack of handling, we review the business logic of a Web service with focus on the needs of each type of capacity requirement. As a result, we define a conversion function that

• • takes two inputs namely a business logic bl (represented here with a state chart) and a set of capacity requirements, that is, $$\[--><$> {\scr C}{\scr A}{\scr R}_{{{\scr W}{\scr S}}}^{{i\, = \,1, \ldots, n}} <$><!--$$ (Definition 2), and

• • returns one output, which is a revised business logic $$\[--><$> b{{l}_{{\scr C}{\scr A}{\scr P}}} <$><!--$$ that shows the capacities that are necessary to satisfy this set of capacity requirements.

This conversion creates the missing link between the business logic and the capacities through the link that exists between capacities and capacity requirements (Definition 2). The conversion function is as follows (Definition 7).

The conversion function Conv takes a business logic bl and a set (possibly empty) of capacity requirements ( $$\[--><$> {{2}^{{\scr C}{\scr A}{\scr R}}} <$><!--$$ is the power set of $$\[--><$> {\scr C}{\scr A}{\scr R} <$><!--$$ ) and produces a revised business logic $$\[--><$> b{{l}_{{\scr C}{\scr A}{\scr P}}} <$><!--$$ . This process is done manually, that is, designer driven. An illustration of a revised business logic is given in Figure 4.

Figure 4

Reviewed business logic of WeatherWS

Because of the conversion exercise, the initial goal, which identifies the functionality of a Web service, is revised with respect to the new mechanisms (in terms of capacities) that empower this Web service. These mechanisms are used for satisfying the capacity requirements. This empowerment has to be captured and reflected on the initial state chart of the business logic of a Web service and can be implemented through three types of actions: states to repeat, states to add, and states to skip (the outcomes of these actions are represented in Figure 4) with dashed lines.

States to repeat. This occurs when the execution of the actions in a certain state did not permit meeting a certain capacity requirement that is put on the Web service. This is detected by checking the post-conditions $$\[--><$> (C \bullet ) <$><!--$$ of this state, which results in repeating the execution of these actions.

For example, report-delivered state in WeatherWS will be repeated if the minimum acceptable network-bandwidth requirement drops below a certain threshold (report-delivered's $$\[--><$> C \bullet <$><!--$$ : network bandwidth did not improve). The objective is to guarantee the delivery of weather-forecast report. Report-delivered state is now bound to a capacity requirement of type network.

States to add. This occurs when the preparation work that is carried out to execute the actions in a certain state did not permit meeting the capacity requirements that are put on the Web service. This is detected by checking the pre-conditions $$\[--><$> ( \bullet C) <$><!--$$ of this state, which results in adding new states to the state chart of this Web service. The new states will be executed several times (obviously bound to a maximum number) until their post-conditions permit satisfying the pre-conditions of the state they precede.

For example, city-located state will be preceded by verification state if the minimum security-level requirement is not guaranteed. The goal is to restrict the use of WeatherWS in an unsecure environment (city-located's $$\[--><$> \bullet C <$><!--$$ : unsecure environment). Contrarily, verification state is simply ignored. City-located state is now bound to a capacity requirement of type security.

States to skip. This occurs when the number of times that the execution of the actions in a certain state reaches the maximum following the continuous unsatisfaction of a certain capacity requirement that is put on the Web service. This is detected by checking the post-conditions $$\[--><$> (C \bullet ) <$><!--$$ of this state, which results in skipping some of the next states and make the Web service take on appropriate states.

For example, weather collected, access-failed, and search canceled states will be ignored if city-located state cannot satisfy the minimum freshness-level requirement of the data it collects out of the database. (city-located's $$\[--><$> C \bullet <$><!--$$ : data freshness is 2 days old). The objective is to guarantee the use of up-to-date data. City-located state is now bound to a capacity requirement of type data.

Note. The fact of repeating, adding, or skipping statesFootnote ⁴ impacts the set of transitions that are established in the initial state chart of the business logic of the Web service (Figure 3). As a result, new transitions are considered if needed.

Figure 4 shows now the reviewed state chart of WeatherWS after making some changes in its initial state chart (Figure 3). These changes show some requirement types that are anchored to some states in this Web service.

While the functionality of a Web service remains the same, the business logic is reviewed $$\[--><$> {\scr R}{{{\scr G}}_{{\scr W}{\scr S}}}\, = \,(fct,rbl) <$><!--$$ like Figure 4 illustrates.

4.1 Description

This section discusses the deployment of capacity-driven Web services following their engineering. In Figure 5Footnote ⁵, a composition scenario (e.g. cookout party) is shown with two Web services: WS₁(CateringWS) with foodCatering as a functionality and WS₂(GuestWS) with guestContact as a functionality. Both WS₁ and WS₂ need to satisfy some composition requirements (Section 3.2.1) before they participate in this scenario. At run-time, these Web services execute their respective functionalities by selecting and activating the appropriate capacity with respect to the current environment requirements (Definition 2). The deployment of capacity-driven Web services goes through four steps:

Figure 5

Engineering capacity-driven Web services deployment

• • Step 1 defines the functionalities of Web services, the capacities of each Web service that implement these functionalities, and the requirements under which these Web services participate in compositions and these capacities are activated.

• • Step 2 searches for the relevant Web services based on their respective functionalities. This step is user need-driven and UDDI-based (or any other type of registry).

• • Step 3 checks with the Web services identified in Step 2 if they would be interested in participating in a composition scenario. Prior to replying either positively or negatively, these Web services verify if they could meet the current composition requirements. A stated earlier an example of composition requirement is the maximum number of compositions to take part in at a time.

• • Step 4 prepares the Web services of Step 3 for execution. This means identifying the execution requirements (or environment assessment) to satisfy so that the appropriate capacities in these Web services are activated. As stated earlier an example of capacity requirement is data freshness. It is noted that any activated capacity in a Web service can be disabled if this capacity can no longer satisfy the current requirements due to changes in the environment. A sudden decrease in network throughput results in first, disabling the current activated capacity in a Web service and second, screening other capacities in this Web service for possible activation as per Step 4.

When these four steps are completed, the composition scenario of Figure 5 could be implemented as follows where ‘→’ stands for ‘next’: WS₁(Cap₁:Op₁,Op_j,Opm) → WS₂(Cap₂:Op₁). Another configuration like WS₁(Cap₂:Op₁,Opm) → WS₂(Cap₂:Op₁) can be adopted but this is not the case due to the current requirements. Current practices in the field of Web services neither specialize the operations to execute nor confine these operations into dedicated modules. These operations are, however, usually woven into and scattered across the business logic of a Web service. As a result, this makes any change in both business logic and operations extensive, expensive, and error-prone (Ortiz et al., Reference Ortiz, Hernndez and Clemente2006).

4.2 Deployment

Figure 6 illustrates the managers in the prototype that implements capacity-driven Web services with focus on Steps 2 and 3 (Section 4.1). The composition manager helps designers define composition scenarios. The discovery manager identifies the Web services that satisfy users’ needs by searching the $$\[--><$> {\scr C} <$><!--$$ -WSDL service registry. Finally, the requirement manager assesses the environment in terms of data, resource, and network prior it sends the details collected back to either the composition or the discovery manager.

Figure 6

Prototype architecture with focus on discovery and composition steps

When the composition manager receives a user's request (Figure 6, action 1), it asks the discovery manager to look for the component Web services that could take part in the composition scenario of this request (action 2). These component Web services are established after the discovery manager screens the $$\[--><$> {\scr C} <$><!--$$ -WSDL service registry (actions 3 and 4). Afterwards, the discovery manager asks the requirement manager to assess the current environment so that data-, resource-, and network-related requirements are identified (actions 5, 6, 7). This would identify the capacities to use per component Web service and per type of requirement. When the composition manager receives the list of component Web services and capacities (action 8) from the discovery manager, it selects the component Web services that will participate in the composition using the composition requirements that the requirement manager sends (actions 9, 10).

Figure 7 details the aforementioned prototype architecture architecture with focus on Step 4 (Section 4.1). Given a selected Web service, the invocation manager identifies the capacity to trigger. The requirement manager assesses the environment in terms of data, resource, and network as described above. The execution manager executes the selected capacity. This execution manager is implemented using Aspect-Oriented Programming (AOP).

Figure 7

Prototype architecture with focus on the enactment step