Architecture for Service Profiling

Witold Abramowicz, Monika Kaczmarek, Marek Kowalkiewicz, Dominik Zyskowski Department of Management Information Systems, The Poznan University of Economics, Poland

{w.abramowicz; m.kaczmarek; m.kowalkiewicz; d.zyskowski}@kie.ae.poznan.pl

Abstract

Service oriented architecture is gaining momentum. However, in order to be successful, the proper and up-to-date description of services is required. Such a description may be provided by service profiling mechanisms, such as one presented in this article. Service profile can be defined as an up-to-date description of a subset of non-functional properties of a service. It allows for service comparison on the basis of non-functional parameters, and choosing the service which is most suited to the needs of a user. In this article the notion of a service profile along with service profiling mechanism is presented as well as the architecture of a profiling system.

1. Introduction

Web Services are emerging as one of the best technologies for implementing Service Oriented Architectures (SOA) and for facilitating enterprise application integration. Facing the rapid growth of SOA the need to obtain as reliable information on services as possible arises. The market of services is not static and the number and properties of services change constantly [1]. With the augmented appearance of services substitutes (services offering the same functionality), emerges a need to distinguish the most suited ones to the needs of clients. That is why, in order to efficiently utilise services, their actual profiling description is required. Service profile may be defined as an up-to-date description of a subset of non-functional properties of a service. It allows for services comparison on the basis of non-functional parameters and choosing the service most suited to the needs of a user.

Nowadays, typical service description available on the Web does not provide necessary information to create its profile. Providers who want to advertise their services in the publicly available repositories have to provide the services description expressed in some language e.g. WSDL [2], OWL-S [3], WSMO/WSML [4] or WSDL-S [5]. The problem is that this description may be incomplete, incorrect or even inadequate. A service provider may include only a few of non-functional parameters in the service description (e.g. some values of Quality of Service). That is why the other important parameters have to be determined by other means.

It is also very important to note that the description provided by service providers is rather static, whereas the values of some service characteristics change over time and depend strongly on changes in the environment (problems with network, throughput, etc.). The main task of Service Profiling System is to create and update service profiles of atomic and composite services utilised on the services’ e-marketplace.

In this article the architecture and mechanism of a Service Profiling System will be presented. First, in the section 2 the related work is discussed. Then, a motivating scenario that will justify the need of service profiling system is presented. In the next section the basic definitions relevant to the concept of service profiling are presented, starting from the notion of service profile, through the sources of information for profile computation, to the mechanisms used in order to obtain values of service profile. In the following section the architecture of Service Profiling System is shown. Finally, the conclusions and future work is given.

2. Related work

Web services technology is a very active research area. The ultimate challenge is to propose an adequate service description method. Many research efforts focus on developing ontologies that capture the main properties of services [3, 4, 5]. Nevertheless, we believe that so far not enough work has been done in order to represent the non-functional features of Web services [6], the most important part of which concerns their Quality of Service properties. Some research initiatives focused on building QoS semantics and ontology management schemes for Web Services. Nevertheless, they mainly developed QoS ontology vocabularies, identifying the various QoS parameters that are involved in Web Service provision [7, 8, 9]. However, as QoS parameters are something more than just type-value pairs, the need to develop a flexible, descriptive, and widely applicable solution for the representation of heterogeneous QoS parameters in a machine understandable manner, while supporting reasoning functionalities, has risen.

While the aspect of Quality of Service (QoS) has been omitted for a significant period of time, it is now clear that without offering services of good quality, providers will not survive on the competitive Web services market. As

Proceedings of the IEEE Services Computing Workshops (SCW'06)0-7695-2681-0/06 $20.00 © 2006

stated earlier, the one common QoS model has not been developed so far [10]. One of the reasons is that it is quite easy to enumerate simple characteristics of Web services, inherent to all of them, such as network-related properties, whereas when it comes to Quality of Result (QoR) it is problematic to create one model for services provided in every domain (e.g. customers expect different things from banking services and different from location services).

There are quite a lot of initiatives aiming at computation of values of QoS parameters on the basis of data collected from different sources. Some researchers focus more on the sources of data, like e.g. service providers (service registries), users, verification centres, monitoring mechanisms [11, 12, 13], whereas others focus more on the algorithms and methods used to compute the values of both atomic and composite services [14, 15, 16, 17, 18]. There exist a few platforms that use and operate on such additional information like e.g. Web services filtering system [19]. However, to our best knowledge, the profiling system like the one presented in this article has not been yet developed.

3. Motivating scenario

Nowadays we observe the growth of the number of services offered on the market. This tendency will not surely loose on its strength and new Web services, along with service substitutes will keep appearing. So far, Web service marketplaces have very basic mechanisms helping users to choose the most suitable Web service from the bigger set. There are some requirements that need to be met in order to make the service differentiation feasible. First of all (1), the non-functional parameters must be taken into account, as every customer perceives the service not only from the side of what functionality it gives, but is also interested in non-functional properties of the service. The next issue (2) is to deliver a QoS model that everybody would accept. Such a standardized QoS is the first step to the agreement on monitoring mechanisms, common SLAs and other elements that should be the parts of every mature marketplace. The last challenge (3) is to create adequate description of a service that will give user (or its agent) hints about the distinctive features of service substitutes. Thanks to the monitoring it should be possible to analyze the information coming from service executions, SLA violations, etc. Assuming that we know users’ preferences concerning service quality and duration of SLA, it is possible to give them some information about past service behavior. Basing on the execution data and users’ preferences, it is reasonable to create so-called profile which reflects QoS values of a given service in a considered time horizon. Moreover, the user should be capable of ranking these profiles and choosing the most suitable Web service. Such a mechanism is implemented

in the Adaptive Services Grid (ASG) platform [20] (http://www.asg-platform.org/). The main goal of the ASG project is to develop a proof-of-concept prototype of a platform for adaptive services discovery, creation, composition, enactment as well as negotiations and service profiling. The ASG service delivery process is presented in the figure below.

Figure 1. Service Delivery process in the ASG [22]

In the Dynamic Supply Chain Scenario [21], created for the needs of the mentioned project, an example of an end service customer, who wants to register a new Internet domain name and configure a web server, is considered. Hence, the scope of the Dynamic Supply Chain (DSC) scenario is: checking whether the desired domain name is free, creating and setting the desired Web hosting account, and finally paying for all services through electronic channels. Services in this scenario are divided into three groups: domain services, web hosting services, payment services.

An exemplary use case of the DSC scenario can be the processing of the user request: “Register domain braun.de for the customer Max Braun and provide him with 100MB of webspace”. Moreover, the customer needs a domain to be registered in less than 1 minute and the customer has a budget of 15 euros.

First, the ASG platform, on the basis of the user request, composes a flow of service specifications that can fulfil the goal. Afterwards the ASG Negotiation Manager component selects the most suitable service implementation to be contracted by negotiation to each service specification. However, for some specifications there is more than one service that implements the service specification – e.g. implementation of CheckDomain service is offered by four different service providers. That is why the Negotiation Manager (NM) needs to choose one of the substitute services, which is the best service according to the user preferences. In order to do that, the values from service profiles and service ranking provided by the Dynamic Service Profiling system are required. That is why for each relevant service (for each substitute) the service profile is created. They must be as precise as possible to describe the service behaviour and service quality. That is why appropriate algorithms, mentioned in

Proceedings of the IEEE Services Computing Workshops (SCW'06)0-7695-2681-0/06 $20.00 © 2006

the next section of this document, data from monitoring of service execution, and information provided by a service provider are used.

The DSP component creates service profiles for each implementation of service specification and orders them according to the synthetic indicator’s value. Similarly, profiles for all other services involved in the process are created. They are sent to Negotiation Manager, and on the basis of these values, it is able to choose appropriate services and conduct the negotiation process. Additionally, the DSP component is able to provide the Negotiation Manger with profiles of service providers. The provider profile gives information on its reliability, accessibility, etc. This information may be used in order to choose one service from the set of services having the same characteristics.

After the negotiation process the composition definition is enact by appropriate component. Finally the output of is passed to the end user.

4. Service profiling

Service profiling is the process of creating an up-to-date service profiles. Doing this involves discovery and computation of values of QoS parameters. This process should have minimal overhead but should also be able to achieve sufficient trust by users as well as providers. Following and extending Liu et al. [14], a few aspects that should be taken into account were identified: 1. Extensible QoS model - we argue that we need to

come up with a standard QoS model that can be used for all services in all domains, whereas it is not practical (or even possible) to come up with a standard QoR model that can be used in all domains. When evaluating QoR, domain specific criteria should be taken into consideration.

2. Fair and open QoS computation – in the profiling system the information about non-functional properties may be collected from service properties published by service providers, users’ feedback and monitoring data from past executions. However, it is important to note that what the service profiling system does is not the core workflow mining process. It analyzes log files in order to obtain data needed for profiling process. Service profiling system should be able to compare contracted values from SLA agreement against these from execution. Such a data analysis [23] is useful to evaluate real QoS values of each monitored service. The profiling mechanism has to collect relevant values from the log file, interpret events, associate events with these values and use this knowledge in the process of service profile creation. For example, we are able to compute the latency time when we know times of the start and completion of

the activity. When an exception occurs, we may reason about the service reliability etc.

3. Computation of quality of composite services – one of the most interesting tasks of service profiling is to find a way to compute the composite service profile, so to define a mechanism to derive values for composite services from history of executions of atomic services included in the workflow definition.

4. Preference-oriented service ranking – different users may have different preferences and requirements on QoS for every service they need to use. It is highly important to be able to create a ranking of services based on this criteria and preferences. For example, for one user service selection may be driven completely by price, regardless of the time of execution, another user may be interested solely in time because of the deadlines that have to be met.

The all issues mentioned above were considered when creating service profiling mechanism. First of all, information about a service execution was divided into three main categories: 1. Static information – values of service properties that

do not change over time, such as name of the service, provided by the service provider;

2. Semi static information – values of service properties that may change over time, such as quality of service, price – this information changes periodically, but not very often;

3. Dynamic information – values of service properties that may be (and usually are) different in every execution of the service. It relates mainly to the network related Quality of Service.

Another categorisation grouped the considered properties into two categories, namely: 1. Simple properties – values of service properties that

can be monitored on an individual level; this is mostly static information, stored in Service Level Agreement (SLA). Such properties may include latency time, execution cost and so on;

2. Derived properties – where additional manipulation is needed (done by Service Profiling System). Such properties may include reliability, availability and so on.

Service profiles, as an up-to-date description of a service, include dynamically changing parameters of a (composed) service as well as static and semi static information. Moreover, the service profile includes both simple and derived properties. Of course different kind of properties require different method of computation starting from simple taking the value from service provider or user declaration ending at sophisticated algorithms.

Composite service profiles are aggregations of atomic service profiles. Description of a composite service profile is very similar to a service profile, because it treats a

Proceedings of the IEEE Services Computing Workshops (SCW'06)0-7695-2681-0/06 $20.00 © 2006

composite service like an atomic service. That is why the structure of its profile does not differ significantly from the profile of an atomic service. However, the values of some parameters are computed as statistical measures on the basis of characteristics of atomic services included in the composed service.

Figure 2. Excerpt of exemplary service profile schema

During calculation of profile of atomic or composite service, a few data sources are taken into account: 1. Service Repository - storing description of a service

provided by a service provider, 2. Monitoring Data - data coming from monitoring of

execution of a service instance. This data is passed in the form of execution logs as well as workflow events.

3. Data from SLA - data coming from binding Service level agreement, that stores information about contracted QoS values that are later compared against real values coming form service execution. In consequence, it is possible to check to what extent the agreement between provider and consumer is fulfilled.

4. User feedback – data coming from end users of a service,

5. Other sources (e.g. third parties, authentications centers etc.).

The excerpt of a service profile schema is presented in the figure 2. Additionally, service profiling system may provide provider profiles, that show how, in general, behave services of a given provider. These profiles are more quality-oriented, whereas service profiles are more performance-oriented. In this case quality orientation means that time-related QoS parameters are less important than the fact whether a given service was accessible or produced expected result.

The service profiling system uses many different algorithms in order to compute values of parameters included in the profile. Often statistical methods are used, for example identifying mean, maximum, or minimum value. However, a service profile is not to be stored in any repository, but should be dynamically computed when a need for it occurs as each time different needs should be taken into account. Users may need a particular instance of a service only once in a given point of time, or they may need to use the service a few times in a given time period. Therefore, the horizon of the computation must be taken into account. In the first case, short-time forecast of service behavior (a short-term-behavior of the service) is important, and in the second case more attention should be paid to the long-term-behavior of the service, taking into account historical (older) data. That is why computation of, for example, execution duration for an atomic service would look like this - Service profiling system counts the weighted mean value of the parameter using historical execution data in the following manner:

�=

=n

iiij EDxED

1

*

Where: - EDj – execution duration for atomic service j

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="ProfileData"> <xs:complexType> <xs:element name="ServiceProfile" use="required"> <xs:complexType> <xs:element name="BasicData" use="required"> <xs:complexType> <xs:sequence> <xs:element name = "WS-ID" type = "xs:string" use="required"/> <xs:element name = "WS-Price" type = "xs:float" use="required"/> <xs:element name = "WS-MinPrice" type = "xs:float" use="required"/> <xs:element name = "WS-MaxPrice" type = "xs:float" use="required"/> <xs:element name = "WS-ExecutionDuration" type = "xs:float" use="required"/> <xs:element name = "WS-ExecutionDurationFulfilment" type = "xs:float" use="required"/> <xs:element name = "WS-MinExecutionDuration" type = "xs:positiveInteger" use="required"/> <xs:element name = "WS-MaxExecutionDuration" type = "xs:positiveInteger" use="required"/> <xs:element name = "WS-Synthetic" type = "xs:float" use="required"/> <xs:element name = "WS-SlaFulfilmentIndicator" type = "xs:float" use="required"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="AdditionalData" use="required"> <xs:complexType> <xs:sequence> <xs:element name = "WS-PaymentMethod" type = "xs:string" use="required"/> <xs:element name = "WS-ChargingMethod" type = "xs:string" use="required"/> <xs:element name = "WS-Accessibility" type = "xs:float" use="required"/> <xs:element name = "WS-Reliability" type = "xs:float" use="required"/> <xs:element name = "WS-ResponseLatency" type = "xs:float" use="optional"/> <xs:element name = "WS-ResponseLatencyFulfilment" type = "xs:float" use="optional"/> <xs:element name = "WS-MinResponseLatency" type = "xs:positiveInteger" use="optional"/> <xs:element name = "WS-MaxResponseLatency" type = "xs:positiveInteger" use="optional"/> </xs:sequence> </xs:complexType> </xs:element> </xs:complexType> </xs:element> </xs:complexType> </xs:element> </xs:schema>

Proceedings of the IEEE Services Computing Workshops (SCW'06)0-7695-2681-0/06 $20.00 © 2006

- i = 1 … n; n – number of service instances

- EDi – value of execution duration from execution of ith instance of service implementation

- xi – the weight for ith instance of service implementation; weights sum up to 1 and depend on the horizon of the prognosis and of the moment of the observation

Execution duration for composite service is a little bit different. Two separate values might be computed: 1. On the basis of composite service execution data –

using the same procedure as for atomic services. 2. On the basis of atomic services execution data of

services included in e.g. the BPEL plan generated during service composition process. First the average values for each atomic service included in the composition are computed, then the plan is analyzed, the critical path is identified and the hypothetical value is computed as the sum of execution duration of services being on the critical path (e.g. “AND” – the highest value is chosen, “OR”, “XOR” – average execution duration is taken).

Values of other parameters may be computed as a ratio e.g. for accessibility, which means the probability of a successful invocation of service. For atomic services it is computed by dividing number of successful invocations by all attempts to invoke the service in a given period of time.

n

mA j =

Where: - m – the number of all successful invocations of the

service implementation in the given time period

- n – the number of all attempts (successful or not) to invoke the service implementation in the given time period.

Similarly to the execution duration, two separate values may be computed to estimate the value of accessibility parameter for composite service: 1. On the basis of composite service execution data - the

same procedure as for atomic services. 2. On the basis of atomic services execution data of

service implementations included in the BPEL plan generated during service composition. First the accessibility values for each atomic service included in the composition are computed, then the plan is analyzed, the hypothetical value is computed as the product of atomic service accessibility value (e.g. “AND” – the product is taken, “OR”, “XOR” – we assume that the probability of execution of each branch is the same (e.g. if there are two of them – 0,5, if there are three – 0,33333 etc.) etc.).

Entirely different algorithm is used to compute the synthetic indicator value used in order to compare services and create their rankings. We propose a mathematical model of QoS computation based on multiple criteria analysis – deriving the synthetic indicator. The services are compared according to a few characteristics listed below. Each characteristic is assigned a weight, reflecting user’s preferences. However, it is out of scope of this article to present all the algorithms and techniques used in order to create service profiles.

5. Architecture of Service Profiling System

Taking into account the issues discussed in the previous section, the architecture of the Service Profiling System should consist of at least a few components. It should include the Repository that will store the data gathered by the system; it should have component(s) responsible for communication with the data sources. Moreover, it should provide interfaces allowing for asking queries by all interested parties. And finally it should have the Profiling mechanism, responsible for analyzing the data and deriving/computing the values of parameters from service profile. As an example of Service profiling architecture, the Dynamic Service Profiling component of the ASG project mentioned in the motivating scenario section is presented.

Internally, Dynamic Service Profiling is decomposed into subcomponents. The subcomponents reflect the logical architecture of the component. They include: Data Collector, responsible for coordinating data streams from different sources, Service Profiler, responsible for deriving QoS attributes to answer requests, DSP Repository which is the internal component database, Event Manager that handles workflow events.

The architecture of DSP is presented in Figure 3.

Figure 3. Dynamic Service Profiling component architecture

Proceedings of the IEEE Services Computing Workshops (SCW'06)0-7695-2681-0/06 $20.00 © 2006

5.1. Service Profiler

Service Profiler creates an up-to-date profile of the service (or provider), whenever it receives a query. Two types of queries may be distinguished: 1. Request for a profile of composed service taking time

horizon into consideration; 2. Request for profiles and ranking of a set of atomic

services taking time horizon into consideration. When creating profiles, Service Profiler uses the

following data about services: 1. Data from the provider’s declaration (Service

Registry), 2. Values of service attributes form the past execution

(DSP Repository). In order to create a profile, the appropriate values of

characteristics, depending on the prognosis horizon are computed. Then, on the basis of the computed values a synthetic indicator for a service is created. As an interaction with user is not yet implemented, default user preferences are used. After computing the indicators for all of the services returned for the given query, services can be compared and the best of them can be identified.

5.2. Data Collector

In order to create an up-to-date service profile, DSP needs to have a good and consistent set of data to operate on. Data Collector is the subcomponent responsible for collecting all relevant data from different sources (either by a push or a pull method), processing them and saving at a proper level of aggregation in the DSP Repository. All incoming data will be transformed according to the needs of profiling process and stored in the repository. Data Collector has an access to the all sources of information the DSP uses.

5.3. DSP Repository

This subcomponent is responsible for storing all the data relevant to service profiles. DSP Repository is a persistent data storage, which is fed by Data Collector. The data in the DSP Repository is already adapted for the needs of Dynamic Service Profiling process. Only Data Collector can change information in the DSP Repository. Other subsystems have read-only access to the repository. The logical architecture of the DSP Repository is presented in the Figure 4.

Figure 4. DSP Repository - logical schema

5.4. Event Manager

Event Manager is the subcomponent responsible for processing of workflow events and receiving execution logs. It is a kind of handler set on the ASG workflow engine. If any crucial information is included in such an event, it is passed to Data Collector for further analysis.

Usage scenario covers the whole process of log/event analysis. Event Manager plays significant role in this process.

DSP registers its own handler in the Workflow Monitoring component. This handler keeps DSP informed about new events occurring during the workflow execution. If the composed service execution is finished, Workflow Manager creates the log file. Afterwards, this log file is passed directly to DSP component. The log is then analyzed. Workflow execution log file is built on the basis of XML Schema. However, after receiving the log file DSP checks whether the file is properly created. If the file passes validation, it can be parsed. DSP is not interested in all the data contained in the workflow execution file. Only selected branches and leaves are interesting form the perspective of profiling process. Such data is e.g. start date of service execution, finish date, states of service during execution and so on. When parsing is done and all data is collected, the DSP retrieves SLA contract from SLA Manager and then data is analyzed and processed. Finally, it is stored in internal DSP database. Insertion of extracted information is performed by the execution of concrete query. Finally, when the data is in the database, the process of log analysis is successfully finished.

As verified in prototype implementations in the ASG project, such architecture fulfils goals and requirements of a Service Profiling System.

6. Conclusions and future work

While dealing with service, having reliable and up-to-date description of a service is a must. Service profiling and service profiles should be used as a source of reliable, up-to-date information on services. This data should be used e.g. in the negotiation process. Moreover, service profiling mechanism may create rankings of services that allow comparing the services taking into account multiple criteria. In the future, service profiling mechanisms may

Proceedings of the IEEE Services Computing Workshops (SCW'06)0-7695-2681-0/06 $20.00 © 2006

be extended with some additional properties like for example identifying tuning possibilities. Such functionality may improve quality and performance of already designed workflows, that have been executed and that are fulfilling their goals.

The service profiling mechanism is one of the elements that ensure that the platform/markets dynamically adapts to the changes in the environment. As we have shown in the paper, it is possible to provide a feasible architecture of a system, which can be further used in real world implementations of SOA platforms.

7. References

[1] Bachlechner, D., Siorpaes, K., Fensel, D., and Toma, I., Web Service Discovery – A Reality Check, DERI Technical Report, January 2006 [2] WSDL 2.0 http://www.w3.org/TR/wsdl20/ [3] OWL-S, http://www.daml.org/services/owl-s/ [4] WSMO, http://www.wsmo.org/ [5] WSDL-S, http://lsdis.cs.uga.edu/projects/WSDL-S/wsdl-s.pdf[6] Maximilien, E.M., Singh, M.P., “A Framework and Ontology for Dynamic Web Service Selection”, vol. 8, no. 5, September-October 2004, pp. 84-93 [7] Mani, A. , Nagarajan, A., “Understanding Quality of Service for Web Services”, IBM developerWorks, January 2002 (Available via www.ibm.com, last visited April 2006) [8] Tsesmetzis, D.T., Roussaki, I.G., Ioannis V.P., Anagnostou M.E., “QoS awareness support in Web-Service semantics”, In the Proceedings of International Conference on Internet and Web Applications and Services (ICIW'06), IEEE, Guadeloupe, French Caribbean, 2006 [9] Lee, K., Jeon, J., Lee, W., Jeong, S., Park, S., “QoS for Web Services: Requirements and Possible Approaches”, W3C Working Group Note, November 2003 [10] Abramowicz, W. et al., “A survey of QoS issues for the needs of Web Services Profiling", In the Proceedings of ISCA 18th International Conference on Computer Applications in Industry and Engineering 2005, Honolulu, USA [11] Casati, F., Castellanos, M., Dayal, U., Shan, M-C., “Probabilistic, context-sensitive and goal-oriented service selection”, ICSOC’04, New York, USA, ACM Press, November 2004 [12] Ran, S., “A model for web services discovery with QoS”, ACM SIGecom Exchanges, 4(1):1-10, 2003; [13] Sheth, A., Cardoso, J., Miller, J., Kochut, K., “QoS for service-oriented middleware”, in Proceedings of the 6th World Multinconference on Systemics, Cybernetics and Informatics (SCI02), pages 528-534, July 2002

[14] Liu, Y., Ngu, A.H.H., Zeng, L., “QoS computation and Policing in Dynamic Web Service Selection”, in Proceedings of the 13th international WWW conference, New York, USA, ACM Press, May 2004; [15] Menasce, D.A., “QoS Issues in Web Services”, IEEE Internet Computing, 6(6) 2002; [16] Cardoso, J. , Sheth, A., Miller, J., Arnold, J., Kochut K., “Quality of service for workflows and web service processes”. Web Semantics: Science, Services and Agents on the World Wide Web, 1(3):281–308, April 2004; [17] Abramowicz, W., Kaczmarek, M., Zyskowski, D., “Duality in Web Services Reliability", In the Proceedings of International Conference on Internet and Web Applications and Services (ICIW'06), IEEE, Guadeloupe, French Caribbean, 2006 [18] Cardoso, J., “Quality of Service and Semantic Composition of Workflows”, PhD thesis, Universitry of Georgia, 2002. [19] Abramowicz, W., Godlewska, A., Gwizdała, J., Kaczmarek, M., Zyskowski D., “Application-oriented Web Services Filtering”, in Proceedings of the International Conference on Next Generation Web Services Pratcices (NWeSP 2005), pages 63-68, IEEE August 2005 [20] Kuropka, D., Weske, M., “Die Adaptive Services Grid Plattform: Motivation, Potential, Funktionsweise und Anwendungsszenarien” In: Emisa Forum, issue 26/1, January 2006 [21] Steinert, B., Moller, J., Sommer, P., Steinhauer, S., Huttenrauch, S., Queck, T., Hahmann, T., “Dynamic Supply Chain Scenario for Internet Service Providers”, Hasso Plattner Institute for Software Systems Engineering at the University of Potsdam, ASG document, 2006 [22] Krause, H., “Next Generation Service Delivery: Adaptive Services Grid, European Integrated Project”, transIT, 2005 [23] van der Aalst, W.M.P., “Business Alignment: Using Process Mining as a Tool for Delta Analysis”, In the Proceedings of the 5th Workshop on Business Process Modeling, Development and Support (BPMDS'04), volume 2 of Caise'04 Workshops, pages 138-145, Riga Technical University, Latvia, 2004

Proceedings of the IEEE Services Computing Workshops (SCW'06)0-7695-2681-0/06 $20.00 © 2006