Población y economía

To remedy these shortcomings and enable the adaptivity required in future business environments, we develop the Adaptive Service Oriented Architec-ture (ASOA). The ASOA we introduce here is based on SOA, however there are a number of alterations in the design (discussed further in this section).

The adaptivity we seek in ASOA is delivered by adaptiveness of the indi-vidual services. We envision that, similarly to Autonomous Computing, the services act as autonomous units which are able to adapt themselves to their environment.

2.6.1 Adaptive Service Oriented Architecture: Basics

Figure 2.6: The Basic Adaptive Service Oriented Architecture

Figure 2.6 illustrates the basics of the ASOA. Like in SOA, service bro-kerage is used to find new services. The main difference is that a new role is introduced, that of the manager. Following the idea of Autonomic Com-puting at both the side of the provider and the requester a manager controls the services.

With the introduction of management in services, we make a distinction between the manageable (adaptable) service and the manager. The main advantage of this architecture is a clean separation of concerns; the service solely offers business functionality, while management and adaptation are the responsibility of the manager. Managers can interact with each other, for example to establish a contract or to notify changes (cf. Medjahed et al.

(2004)).

We consider reconfiguration of a service to be a managerial task and not an operational, and therefore finding and integrating new services should be done by the manager. Figure 2.6 illustrates this with the connection from the service broker to the manager and not to the service.

We define the manager to be a service similar to the service that it man-ages. By defining the manager as a service, it exposes interfaces similar to the manageable service. The distinction between a standard service and a manager is that a manager has goals and enacts an adaptation cycle.

For the basis of the manager we borrow proven concepts from Agent

Technology. Agents are pieces of software able to make decisions and moti-vate these decisions. The characteristics of agents such as the pro-activeness make agents a suitable candidate to deal with unforeseen changes.

2.6.2 Concepts in ASOA

The concepts we described in the section on SOA together with concepts distilled from papers concerning management, like WSDM (OASIS, 2004;

Bullard & Vambenepe, 2006) and Agents have resulted in the ontology illus-trated in Figure 2.7. In this section, we explain our choices concerning these concepts and describe how they relate to each other.

Figure 2.7: Ontology of an Adaptive Service Oriented Architecture

We distinguish between two types of concepts, namely specifications and artifacts. The specifications represent descriptions and components such as contracts, capabilities, and interfaces, and goals. The artifacts constitute the parts that are implemented such as the service and manager.

Figure 2.7 contains an adaptation cycle which is formed as follows:

The manager listens to the events that are generated by and about the man-aged service. Based on these events, the manager detects changes, that for instance, affect the performance of the service. Depending on it’s goal(s),

the manager decides whether and how to react to the change. The capa-bilities that the service provides are the means for the manager to execute these adaptations. The concepts introduced or altered (in relation to their definition in SOA) are explained in detail below:

• Goal: Software is build with a purpose (or goal). However in non-adaptive software the goal is typically implicit (Dardenne et al., 1993;

Yu, 1997). An area where goals are explicitly used is software agents.

One of the characteristics of an agent is proactiveness, implying that agents are goal-directed. Goals used for Agent programming have two aspects (Winikoff et al., 2002). The first aspect is that can be defined in a declarative manner. In this way, they describe the state of affairs which is sought by the agent. Declarative goals are required if agents need to reason about them. The second aspect is to define goals as pro-cedural, meaning that a goal is defined as a set of procedures which is executed to achieve the goal. Both aspects are required for adaptation, as is explained in Section 2.7.

• Contract: The contract stipulates a mutual agreement between two or more services and defines prerequisites and results of particular ser-vice interaction. As part of the separation between managerial and operational aspects in ASOA, we see negotiation and agreement over a contract as a responsibility of the manager. The contract is im-plicitly included in WSA through the concept of “service semantics”, but in the ASOA we need an explicit notion for restraining the adap-tiveness of the service. Although the services should be adaptive and alter themselves to their environment, stability between parties is of critical importance to reduce uncertainty and establish trust relations.

Among others, one aspect that is suggested to be captured in a contract is Quality-of-Service (Curbera, 2007).

• Capability: A capability is a task that is published in the interface.

In ASOA, we make a distinction between two types of capabilities, namely operational and managerial. The operational capabilities are defined as in the standard SOA. The managerial capabilities, represent the means for adapting the service and to make it comply to the man-ager’s intentions (Kreger et al., 2005). We distinguish between atomic and composite service. In the atomic service the manageability capa-bilities are limited to parameter adaptation and optimization of the

process, whereas in the composite service the manageability capabili-ties entail besides parameter adaptation, compositional adaptation and thus redesigning the (business) process. As operational and managerial capabilities have the same characteristics we do not make a separate concept for each type.

• Event: Events are messages that contain information about the sys-temťs functioning, and are used for the purpose of logging, alerting and monitoring. Events combined with event-correlation models form the basis on which the manager can detect changes, providing the founda-tion for reactive change management. Events are a common architec-tural style for distributed, loosely coupled and heterogeneous software (Rosenblum & Wolf, 1997; Muhl et al., 2006). As can be seen in Figure 2.7, we do not have the concept of message in the ASOA. The reason is that we assume that in asynchronous communication, messages can be equated with events. For the remainder of this thesis, we will use the term event and message interchangeably.