Process Model

Each interaction between customer and provider consists of one or more processes which are modeled using workflow concepts. Our process model which is compatible to WfMC terms is depicted in figure . Processes consist of activities. To enable hierarchical decomposition a process itself is an activity. An activity needs resources to be executed on and data to work with. Both are abstract representatives to be mapped later on. Activities can generate events, e.g., for inter-process communication, synchronization of concurrent paths or for exception handling. Events are also triggers for other processes.

Additionally, the current state must satisfy pre-conditions before an activity is executed and the state must satisfy post-conditions after finishing the execution. Conditions are used for guaranteeing a consistent state before and after the execution of an activity. Events and data of the process as well as system data like current time can be used in conditions.

  

Figure: Process Model

The so far defined parts of the process are highly reusable because all information is service-oriented, while the following mapping is customer dependent. The data needed by activities are mapped to variables and properties. Properties represent values which are defined in the SLA. Variables are highly dynamic values which are exchanged through an interface between customer and provider at run time. An example for dynamic values are the user data in the authorization process while the maximum authentication time is a property.

The resources used by activities are mapped to interfaces. The definition of interfaces hides the implementation details. A resource representing a role can be mapped to a technical interface, e.g. defined by a telephone number, or to an individual contact person.

An important information in a service level agreement are constraints. In combination with properties they specify the service level. Constraints consist of rules with parameters which are also defined in the service level agreement. Rules can refer to values of variables, properties and system data as well as events. An example is ``the overall delivery time of local email may not exceed n minutes during business hours'', where ``n minutes'' and ``business hours'' are parameters of the constraint.