2.7 A Framework using Model Management
2.7.1 Manageable Service
We explain the manageable service through the use of the model of a service described in previous section. A formal representation and description for the concepts in that model is given in Table 2.4. Tasks represent a (busi-ness) process that is captured in for example, BPEL or a Petri-net. The data in events is typically modeled using XML Schema and the interface using WSDL. For the interface, we make a distinction between the operational in-terface (Op.IF) and managerial inin-terface (Man.IF). The manageable service publishes an interface (Op.IF) containing the capabilities that it wants to advertise and a business protocol specifying the order of the messages in-volved. Next to these aspects, a URI to the manager of that service should be included. By publishing this endpoint, communication between managers is realized.
Following a model management approach we define a mapping between the operational interface and the implementation (task) of the manageable service. An advantage of this approach is that properties can be defined on this mapping such that the validity of the mapping can be guaranteed, i.e.,
the implementation conforms to the interface and vice versa. In our frame-work, this is realized by defining the capabilities published in operational and managerial interface to be equal to the set of tasks that the service is able to perform. Thus, let Ta denote the set of tasks of a service then Ta ≡< co1, .., con > ∪ < cm1 , .., cmr >. Note that although the service pub-lishes tasks as capabilities, this does not necessarily mean that all actions performed to realize a task are published as well.
The managerial interface contains all aspects related to the manageability of the service. We make a distinction between two aspects of manageability of a service, namely adaptability and monitorability . Both aspects are required to be present in the manageability interface (Man.IF).
Monitorability refers to the method how the manager will become aware that a change has occurred. This specifies whether the manager will receive information (events) from the manageable service, other managers, third party notification agents, or not at all.
The adaptability of the service refers to how the manager is able to adapt the service, i.e. the manageability capabilities. An important aspect of these capabilities are the operators that are defined on the model. In our framework, these operators consist of adding and removing concepts (and relations) in a model. An example of a set of operators for our ASOA service model is: addTask(), removeTask(), addAction(), removeAction(), addEvent(), removeEvent(). More formally defined: Let Σ be the finite alphabet of operators. A word of length k ∈ N over Σ is a sequence of k symbols in Σ. Let Σ∗ be the set of all words over Σ of length k for some k ∈ N.
Operators are commonly stored in a script. A script α is a sequence of operations that transforms one model into another, more formally defined as M1
o1
→ M2 where M2 is the result of applying the basic operation o1 to M1. For a sequence α = o1, .., om of operations, we say M1
Three properties of a set of basic operators are distinguished, namely completeness, consistency and minimality (Casati et al., 1998).
Completeness refers to the ability to transform a model of a type of model to another model of that same type. Based on this alphabet and model, we define when a set of operators is complete:
Definition 3. (Completeness of operators)
A set of operators Σ for a type of model M is complete iff:
∀M, M′ ∈ M ∃α ∈ Σ∗[M′ α→ M]
Intuitively, Definition 3 means that if all concepts and relations of a type of model can be expressed using operators, then all instances of that type of model can be expressed using only these operators. Exam-ples of types of models are Finite State Machines or Petri-nets. If the manageability capabilities include a set of operators that is complete, then we call the service completely adaptable. Having a completely adaptable type of model provides two advantages. The first advantage is it guarantees that if a change affects the model and if the solution can be expressed in the concepts of that model that a solution can be found. This is further explained for Section 2.7.2 on the manager. The second advantage is that all models of that type can be expressed us-ing only operators, i.e., it can be expressed declaratively. This means that adaptation is equated with finding the right model. Advantage of an declarative model is that line-based versioning systems, such as Subversion 1 can be used to keep track of the change history. We de-scribe an example of a completely adaptable service, i.e. the retailer in Chapter 3.
Consistency of a set of operators implies that after applying a script to a valid model again a valid model is returned. We define a model to be valid if it adheres to a set of properties, also called meta-model. For example a property for a finite state machine may be that every state must have either an incoming or an outgoing edge, i.e. every state in the finite state machine must be reachable. The set of properties defined for a model must hold for every created or adjusted model.
The manageability interface should present the properties that must hold for a model. Let ϕ be a property then the notationM |= ϕ means that the model M satisfies property ϕ.
Definition 4. (Well-formedness of models)
Let < ϕ1, ..ϕn> be a set of properties, a model M is well-formed iff:
∀i ∈ {1, .., n}∀ϕi ∈< ϕ1, ..ϕn> [M |= ϕi]
1http://subversion.tigris.org/
In words, the above definition states that a model is well-formed if and only if it satisfies all properties.
Similar to well-formedness of models, we define well-formedness also for scripts.
Definition 5. (Well-formedness of a script)
Let Mwell denote a well-formed model as defined in Definition 4. A script α is called well-formed if the following property holds:
Mwell
→ Mα ′well
A script is well-formed if both the original model and the new model are well-formed.
Consistency can be guaranteed in two ways: either by specifying vali-dation constraints as precondition for the operators (thereby ensuring that after every operator a valid model is achieved), or by specifying validation constraints that hold for the whole model and check these after all the operators of a script have been applied. Both approaches (if applied properly) yield the same result, namely a valid model.
Minimality of a set of operators refers to the ability of transforming models with a minimal set of operators. Because parameters can be used in the operators to create new instances of concepts, the minimal set of operators for a model contains a single operator, which contains all concepts as parameters. As there are different strategies for defining operators, minimality over different languages of operators is hard to impose. However, we do impose minimality of scripts of operators within the same operator language.
In order to have scripts that change a model, they should not be iden-tity scripts. We define an ideniden-tity script as follows:
Definition 6. (Identity script)
A script α is called an identity script (or identity transformation) if:
M→ M.α
A script of operators is an identity transformation if after applying the sequence of operators on a model, the result is again that same
model. An example of an identity transformation is if a change script contains the addition and removal of the same element. We do not impose minimality on a set of operators, however, we have for each concept exactly two operators, namely add and remove.
Definition 7. (Minimal script)
A script α∈ Σ∗ is minimal (denoted as αmin) for transformation M→ Mα ′ iff:
¬∃δ ∈ Σ∗[|δ| < |α| ∧ M→ Mδ ′]
Intuitively, the definition for minimality states that if a script is min-imal then there does not exist another script that results in the same model and contains fewer operators.
Lemma 1. α is minimal ⇔ ¬∃δ ∈ Σ∗[δ ⊆ α ∧ M→ M]δ
Proof. We assume here that our language Σ contains only add and remove operators. The statement ¬∃δ ∈ Σ∗[δ ⊆ α ∧ M → M] statesδ that “α does not contain an identity transformation”.
⇒: Assume that α is minimal. As scripts contain only addition and removal of concepts, a script is minimal if all operators apply to dif-ferent elements in the model. Thus, for all elements in the script only one operator per element is part of the script. If only one operator per element exists, this means that it can not contain an identity script as this would imply that the script contains two operators for one element.
⇐: Assume that α does not contain an identity transformation. This means that there are no two operators for the same concept, as this script may only contain addition and removal operators only elements can be introduced or removed. If an element is thus not added and also removed this implies that the script only contains operators for different elements, hence is minimal.
Lemma 1 states that if a script is minimal it can not contain, subscripts that are an identitity transformation and vice versa.
The managerial interface of a manageable service provides all functions related to adapting the service. In Table 2.5, we summarize the Manageabil-ity functions. An important function in the manageabilManageabil-ity interface is the
Function Output Description
getOperators() Σ returns the alphabet of operators Σ for the type of model used by the service.
getModel() M returns the model currently used by the service (in the form of operators).
update(α) boolean updates the current model of the service by applying the operators of script α to it, with α∈ Σ∗.
getMetaModel() < ϕ1, ..ϕn> returns a set of properties that must hold for a model to be well-formed.
valid(M) boolean determines whether a model is well-formed.
Table 2.5: Manageability Functions
update function. The manager will use this function to adapt the manageable service to changes. With updateM(α) we denote the function that updates a model M by applying the operators in α to it. When it is clear from the context to which model the operators are applied we omit the model, like update(α).
We complete our description of a manageable service by providing an example specification of the retailer in our running example, see Table 2.6.
In this specification we present the skeleton of the retailer, however this
Concept Example
Actions {receive(event), send(event),..}
Tasks ordermanagement = {receive(order),send(checkAvailability)..}
Events {order, checkAvailability,..,accept}
Capabilities {ordermanagement}
Op. Interface {ordermanagement},
http://example.org/mymanager (URI manager) Operators {addTask(),removeTask(),..},
Meta-model {consistent,..}
Man. Interface see Table 2.5
Table 2.6: Specification for a Manageable Retailer
is not a complete description, for instance the ordering of the actions and messages is not apparent. In the next chapter we will describe the model we use for representing an adaptable orchestrator, and exemplify this in the
context of our running example, i.e. an adaptable retailer. Note that we state adaptable and not manageable because the monitoring aspect of the manageability interface is already set in this specification.