A Two-phase Rating Process for Dynamically Composed Services

6 downloads 113 Views 312KB Size Report
Abstract. Environments offering facilities to compose, on-demand, networked software services offered by multiple providers will require accounting systems that ...
A Two-phase Rating Process for Dynamically Composed Services B. Jennings, P. Malone and S. van der Meer Telecommunications Software & Systems Group, Waterford Institute of Technology, Cork Road, Waterford, Ireland. {bjennings, pmalone, vdmeer}@tssg.org

Abstract Environments offering facilities to compose, on-demand, networked software services offered by multiple providers will require accounting systems that have the ability to charge for composed services in a manner reflecting the potentially complex business agreements between these providers. We present a two-phase rating process that allows rating engines generate charge information for dynamically composed services without having to have a priori knowledge of the structure of these services. In the first phase individual services comprising the composed service are rated as if they were executed standalone. In the second phase these interim charges are modified in line with providers’ rules regarding whether monetary discounts or penalties should be applied when their services are used with other services. We discuss the ongoing implementation of this process in the context of an enhanced Rating Bureau Service and its deployment in the “Digital Business Ecosystem” environment. Keywords Accounting, Rating, Service Oriented Architectures, Service Composition

1.

Introduction

Many researchers are pursuing the vision of service-oriented architectures through which businesses and individual users can seamlessly access customised and potentially disposable software services to aid them carry out a myriad of tasks. Full realisation of this vision requires deployment of facilities for the dynamic discovery, composition, interoperation and execution monitoring of pre-existing networked software services; services that are possibly offered by different vendors and developed by multiple developers, using different development tool sets. Although increasingly powerful methodologies, languages and algorithms supporting both the

1

construction, execution and adaptation of dynamically composed services are emerging, little attention has been paid to the supporting infrastructure necessary for their widespread deployment and management. The task of effectively managing systems in which the services provided can be dynamically composed is significantly more complex than that of managing systems in which the services provided are known in advance. Existing management systems typically target management of services on an individual basis; they do not consider the possibility that services can be collectively orchestrated in an almost arbitrary manner to fulfil changing requirements. It is unclear how these management systems can be evolved to provide, for example, performance assurance, service-level security, accounting or fault detection for dynamically composed services. We consider service usage accounting to be one of the most pressing issues, since the commercial success of systems facilitating dynamic service composition will be contingent on the ability of providers to charge and collect appropriate fees for service usage. Our work is focussing on the development of a framework enabling flexible charging for composed services comprised of services offered by multiple providers. In this context the key challenge is to realise a model reflecting the potentially complex business agreements between multiple providers that can provide for automated charging for composed services of which the accounting system may have no a priori knowledge. Since these composed services may be constructed and executed “on-the-fly” to meet changing demands, the accounting systems must also be appropriately configured in a dynamic and automated manner. This represents a significant departure from existing acocunting systems, in which all components are manually pre-configured to support new services in advance of service activation. This paper presents a two-phase rating process for dynamically composed services that provides service providers with the ability to design charging schemes for their services governing both the charges generated for usage of these services on a standalone basis and the charges generated when the services are used in conjunction with other services. To motivate the need for this process we first briefly review the state of the art in networked service accounting. We then provide a generalised view of the service composition environments in which the process could be employed. After specifying the two-phase process itself we describe how it is being implemented as an enhancement to a previously developed advanced rating engine prototype and discuss its deployment in the Digital Business Ecosystem business-to-business environment. Finally, we draw conclusions and outline plans for further work.

2

2.

Accounting Systems State of the Art

Accounting has been described by the standards body IPDR.org in [1] as: “the process of collecting and analysing service and resource usage metrics for the purposes of capacity and trend analysis, cost allocation, auditing, and billing, etc. Accounting management requires that resource consumption be measured, rated, assigned, and communicated between appropriate business entities” As shown in Figure 1 below accounting systems for (post-paid) networked services typcally incorporate facilities for metering, mediation, rating and billing. Service Plane

Accounting Business Logic

Network Plane Pre-configured metering records correlated, formatted records

Mediation

Rating

charge records

invoices

Billing Customer

Figure 1: Accounting System for Networked Services Metering takes place within the network infrastructure; it is concerned with the accurate recording of service usage data and exposing collected metering records to the mediation subsystem. Mediation involves reliable collection of metering records from metering devices; correlation of records relating to the same service usage sessions; transformation of disparate metering record formats into a common format suited to the needs of the rating subsystem; and reliable transfer of processed records to the rating subsystem. Rating involves the application of models (charging schemes) for the mapping of usage data to monetary units based on various criteria: each record received from the mediation subsystem is examined and the appropriate charging scheme is applied, resulting in the generation of a charge record for the service session. Finally, for post-paid customers, the Billing subsystem collates charge records for individual customers, who are invoiced on the basis of these charge records, and any additional subscription fees and discounts. Accounting for services, including composite services, whose characteristics are known in advance, is a relatively mature area. For example, in the telecommunications domain there is wide deployment of complex accounting systems supporting sophisticated usage- and content-based charging schemes for pre-paid and post-paid, private and corporate, customers. Such systems are typically optimised for reliability and speed, with the components involved in the accounting process being manually configured to account for specific services at the time those services are initially deployed. However, even for relatively simple, standalone services, configuration of accounting operations is today a time consuming and costly activity.

3

Large businesses, such as telephone network operators, invest considerably in complex systems to track usage of their services and charge customers accordingly. The European Commission funded IST FP5 project FORM recognised that the emergence of the business-to-business e-Commerece market was influencing how services were being provided, charged and billed for. One of the challenges addressed by the project was that of providing a service bill that integrated charges for individual service usage of those services constituting a composed service. As a solution the project introduced the concept of an Inter-Enterprise Service Provider (IESP), a business entity that acts as a broker between a service consumer and the third party service providers, consolidating the charges relating to third party service providers and presenting the service consumer with a single bill. The IESP is responsible for the service composition and the management of relationships, contracts, usage data and financial transactions between the service providers and consumers. This approach has been termed Federated Accounting [2] in that it specifically supports the requirement for service providers to cooperate in the provision of composed services in a federated manner and share the generated revenue. However, the approach addresses only statically composed services – an IESP will need to have pre-configured the accounting process for a service well in advance of deployment of that service. Agarwal et al. [3] propose a method for metering and accounting for composite e-services, which is not dependent on a-priori knowledge of the service composition. However, their approach supports only two specific service charging models (flat rate per amount of resource used and flat rate per transaction). More significantly, the charge for an invocation of a composed service will always be the summation of the charges associated with standalone invocations of the constituent services; as discussed above, this will not always reflect the business relationships between the service providers. For example, providers may wish to offer discounts if their services are used in conjunction with services offered by a partner, or conversely charge a premium if they are used with services of a competitor. The intention of these measure would be to provide cost incentives for the use of particular service combinations over other combinations providing the same, or similar, functionality.

3.

Service Composition Environment Model

Our model of a commercial multi-provider composed service execution environment is illustrated in Figure 2 below. This environment contains services that can be composed together and various components that support the service composition, execution and accounting processes. The Service Composer is responsible for constructing service compositions to meet specific requirements, whilst the Workflow Manager is responsible for coordinating the execution of composed service invocations. Accounting functionality is provided by a Rating Engine and a Billing System. For simplicity we omit other accounting relating components, such as

4

mediation systems, CRM systems, or fraud management systems. As individual services are consumed metering records, detailing service utilisation patterns, are generated and forwarded to a Rating Engine, which, as described in §2, is responsible for applying charging schemes that map service usage data contained in those metering records to monetary charges. The Billing System accepts charge records from the Rating Engine and consolidates them to generate customer invoices. We assume that all services are offered on a post-paid basis. Provider B

Composed Service Execution Environment Provider A

Workflow Manager

Service Composer

Execute

Compose

D C

B A

services

Rating Engine

Billing System

Rating Engine Provider C

invoices

Figure 2: Generalised Composed Service Execution Environment From the accounting perspective, providers can adopt a number of approaches in offering services, specifically: •



Services are offered as atomic services (e.g. service B in Figure 2): In this approach services appear as individual (non-composed) services for which metering records identifying the service type in question are generated, and for which specific charging schemes are available. Note that these services may actually be realised by the provider as compositions of other services, but for operational or commercial reasons the provider may wish to mask this; Services are registered as atomic services and the provider itself controls generation of charge information for the service (e.g. service D in Figure 2): In this approach services again appear as atomic services, even if they are actually realised as service compositions. However, the provider also takes responsibility for generating charge information for the service, either by maintaining its own rating engine, or by using a rating engine provided by a trusted third party. Thus, if the service is itself used as part of a “higher-level”

5



service composition, its rating engine would be queried by the rating engine responsible for the higher level service – we refer to this as federated rating; Services are registered as composed services and the services comprising that composed service are identified (e.g. service A in Figure 2): In this approach the structure of the offered composed service is transparent to the execution environment. Metering records are generated by the (atomic) services comprising the composed service, and the accounting components identify these records as relating to an invocation of the composed service. The composed service may or may not have a specific charging scheme associated with it; if not, the rating engine must be able to calculate charges on the basis of the collection of charging schemes associated with the individual services.

For the purpose of accounting we model composed services as hierarchical collections of atomic and composed services, as illustrated in Figure 3. The service at the top level of the hierarchy is the master composed service – the service to be rated. Services at the bottom of the hierarchy are all atomic services (they cannot be further decomposed for accounting purposes). We call a group of service directly composed together a composition group. A rating engine must have access to either a charging scheme for an atomic service in order to rate metering records for invocations of that service, or have the ability to query another rating engine to ascertain the charge associated with that invocation. master composed service

atomic service

composed service

composition group

Figure 3: Composed Service Model for Accounting Purposes All Service instances have associated with them a providerID, which uniquely identifies, across the entire environment, the business entity offering that service. They have a serviceID, which uniquely identifies the service type within the set of service types provided by the business entity with the service instances’s providerID. They also have an instanceID, which uniquely identifies an instance of a service type within the set of instances of services with the same serviceID and providerID. This

6

reflects the fact that a service provider may maintain multiple instances of the same service type, and the potential need to distinguish between these instances for rating purposes. Therefore, the tuple of (providerID, serviceID, instanceID) uniquely identify a service instance across the entire environment. In order to accurately rate dynamically composed services it is of critical importance is able to detect the context in which an atomic service it is rating is being executed – as a standalone atomic service, or as part of a particular composed service. Our approach is to have the workflow manager assign a unique transactionID to every invocation of a composed service. The transactionID uniquely identifies the invocation of the master composed service during the timeframe between initial invocation and the completion of all processing associated with that invocation. It is passed to every service comprising that composed service and is included in all metering records relating to those services. This approach has the advantage that services do not need to be aware of their full execution context (at least for accounting purposes). Furthermore, every service instance executed within the context of a composed service is passed an invocationID which uniquely defines that invocation of that service instance within the context of the master composed service. Thus, if a master composed service involves two or more independent invocations of the same instance of a given service these invocations can be distinguished. We assume that when the workflow manager is about to execute a composed service it knows the location of a rating engine capable of rating this service. A rating engine is capable of rating a composed service if charging schemas associated with all the atomic services making up that composed service can be accessed, directly or indirectly, by that rating engine. Direct access to a charging scheme implies that the scheme is deployed on the rating engine, whereas indirect access implies that the scheme is deployed on another rating engine that can be queried.

4.

Two-phase Rating Process Specification

In this section we specifty the two-phase rating process for composed services. During the process atomic services comprising a master composed services are each initially rated as if they were executed standalone; subsequently, in the second phase, a charge for the composed service reflecting modificiations to atomic service charges is generated. To faciliate this process we use charging schemes consisting of two distinct parts: part 1 dictates how charges are to be calculated when the service is invoked in isolation (not as part of a composed service); whilst part 2 dictates any modifications to charges generated by application of part 1 in cases where the service is invoked in the context of a composed service. Charging schemes can be associated with both atomic and composed services, however charging schemes for composed services only have a part 2 and not a part 1. We now outline the process in terms of its initialisation, its phase 1 and its phase 2:

7

Initialisation Before invoking the master composed service the workflow manager sends a notification to the rating engine containing: the transactionID to be contained in all metering records associated with that invocation; the providerID, serviceID and instanceID for the master composed service itself; and a description of the underlying service composition hierarchy. We use XML to represent the hierarchy, as illustrated by the example shown in Figure 4 below. For those services the rating engine will not be able to rate directly the notification will also contain identity and location information for a rating engine that can provide the necessary charge records. The rating engine ascertains whether it does indeed have direct or indirect access to all the required charging schemes; if it does, it sends a response to the workflow manager indicating that it is ready to commence rating the master composed service. X

A

B

Y

C

D

Figure 4: Representation of an example composed service hierarchy Phase 1: Rating Atomic Services as standalone services As the atomic service instances comprising the composed service are invoked and executed metering records relating to them are transferred to the rating engine (in the case where the rating engine has direct access to the associated charging scheme). Every such metering record received by the rating engine is rated using part 1 of the charging schema associated with that service, with the first one resulting in the generation of an interim charge record for the associated invocation of the atomic service instance. As well as the monetary charge, interim charge records include the transactionID, serviceID, instanceID and invocationID. Subsequent metering records for this service invocation result in the generation of a monetary charge and the charge value in the interim charge record is incremented by this value. The rating engine continues processing metering records in this manner until it receives a notification from the workflow manager that execution of the master composed service has completed successfully. Phase 2: Modification of interim charges and overall charge calculation In the phase 2 the interim charges generated in phase 1 are modified in accordance with the part 2 of the service’s charging scheme. Part 2 contains rules specifying how much a charge is to be incremented or decremented by if other services are present with the same composition group in the service composition hierarchy of the master

8

composed service. The intention is to allow providers specify discounts or penalities to incentivise or disincentivise composition of their services with other services. Note that we are assuming that service cost will be used as one of the primary criteria used by a service composer when choosing between services that provide similar functionality. Discounts or penalties can be applied, for example, as fixed amounts, percentages, or as varying fixed amounts / percentages based on the absolute value of the interim charge. The rules can specify that they be applied based on the presence of services with specified combinations of providerID, serviceID and instanceID. Thus, a charging scheme part 2 could specify that a service is discounted by a percentage value if it is used with another service offered by the same provider, or that a fixed penalty be applied if the service is used with a service offered by a competitor. The initial step for the rating engine in phase 2 is to contact other rating engines to ascertain the charges generated for those services for which the rating engine did not itself do phase 1 rating. To do this we use a simple query/response protocol in which the query message specifies the transactionID, serviceID, instanceID and invocationID and the response message specifies the absolute value of charge and the currency unit. These charges remain constant during the remainder of phase 2 – discounts/penalties are not applied to them. The rating engine employs a recursive algorithm to calculate discounts/penalties and ascertain the overall charge for the invocation of the master composed serivce. The notation used to describe this algorithm is described in Table 1. Table 1: Notation for composed service charging algorithm Notation

Constaint

sm {S M } M {S D }

M ≥2

D {S O }

2≤ D≤M {S O } ⊂ {S M }

si {S si } ni ci

si ∈ {S M }

Δci cm

0 ≤ ni ≤ M − 2

Definition the master composed service the set of all services of which sm is comprised. the number of all services of which sm is comprised the set of services of which sm is directly comprised (i.e. the top level set of service which are combined together to realise sm ) the number of services that directly comprise sm the subset of services comprising sm that are rated by other rating engines an arbitrary service of which sm is comprised the set of services of which si is comprised the number of services that service si is comprised of the charge associate with service si in the relevant interim charge record the change in ci as a result of phase 2 of the rating process the final charge associated with sm

9

The algorithm employs recursion, with the master composed service composition hierarchy being traversed so that charges related to composition groups lower in the hierarchy are processed before those at higher levels. Charges for these groups need to be calculated first, as they are needed for calculation of charges at the higher levels. The algorithm is outlined in Figure 5 below. Inputs:

{S M } , {S D }

Output:

cm

1: 2: 3: 4:

Function: ratePhase2CompServ( {S X } ) { For all si ∈ {S X } such that ni > 0 do: ratePhase2CompServ( {S si } )

5:

For all si ∈ {S X } such that ni = 0 and si ∉ {SO } do:

6:

For all services s j ∈ {S X } , where si ≠ s j do:

7:

Calculate Δcij = f (ci , c j ) , where ∆cij is the change in ci mandated by the

8:

Set Δci = Δci + Δcij

presence of s j in {S X } . 9:

Set ci = ci + Δci

10:

Set ck = ck + ci , where ck is the charge associated with the service sk for which {S sk } = {S X }

11: } 12: 13: 14: Start 15: 16: Set cm = 0 17: For all si ∈{S M } do: 18: Set ci = 0 19: Set ∆ci = 0 20: 21: ratePhase2CompServ( {S D } ) 22: return cm

Figure 5: Composed service charging algorithm The algorithm produces a charge for the invocation of the master composed service. This charge is put into a charge record for the invocation, along with the providerID and serviceID of the master composed service, the transactionID, and any other information taken from the metering records that is required by the billing system, in

10

particular the consumerID associated with the service consumer. This charge record is subsequently transferred to the billing system for further processing.

5.

Rating Bureau Service enhancements for two-phase rating

The Rating Bureau Service (RBS), developed during the IST FP5 AlbatrOSS project [4], provides a basis for a rating engine exposed via a Web Services interface. The RBS adheres to the IPDR NDM-U protocol [5], a standard for describing and conveying rateable events for IP services in XML format (though it can be readily applied to arbitrary non-IP service types). The RBS also includes a Web Services implementation of the IPDR document transfer protocol for exchange of IPDRs between mediation and rating components. To ensure that the RBS is capable of peforming the two-phase rating process described above, it is necessary to enhance the existing stateless rating process implementation to provide for a stateful rating process. This is due to the fact that the phase 2 of the process can only be performed once the rating engine is aware of the successful completion of the execution of master composed service instance. As stated above, the current incarnation of the RBS exposes an interface which allows for service elements or mediation systems to push IPDR usage data for subsequent charging. Several records, each detailing usage events of an atomic service instance, can be passed to the RBS per data transfer. For each of these records the RBS first stores the data record in a ‘unrated’ table in a database and then determines the appropriate charging scheme for the usage instance, extracts relevant values from the usage data and inserts these into the charging scheme. Charging schemes in the RBS are realised as worksheets containing named cells denoting which elements of the usage data should be inserted [6]. The appropriate parameters are read from the record and inserted into the worksheet. The charge is calculated by a spreadsheet engine and then read from a ‘charge’ named cell. This resulting charge is inserted into the record in a charge element. This becomes the interim charge record, which is then stored into a ‘rated’ table in the database. This is phase 1 of our two-phase rating process. In order to perform phase 2 of the process the RBS needed to undergo a design enhancement. As indicated in §4, the algorithm applied in phase 2 requires that the rating engine is aware of the structure of the master composed service instance and that it is notified of the invocation and termination of this instance. Thus, the enhanced RBS is required to: 1.

be capable of acting as a ‘supervisor’ rating engine. This means that the RBS must be able to take responsibility for charging for a master composed service, querying other rating engines for charges relating to services in the composition hierarchy that it is not itself responsible for rating;

2.

be aware of the structure of the master composed service’s composition hierarchy, as indicated by the workflow manager. This information is required for the

11

phase 2 algorithm that calculates discounts/penalties and computes the final charge for the master composed service invocation. 3.

understand the current ‘state’ of the service consumption. In effect this means it must be capable of recording when the invocation of the master composed service has started and when it has terminated. During phase 1 of the process all generated interim charge records must be stored until they can be finally process by the phase 2 algorithm.

The first of these requirements means that the RBS must be enhanced with the ability to contact other rating engines using a simple query/response protocol, or conversely, to act as a supervised rating engine providing charge information to other rating engines. The introduction of this inter-RBS communication mechanism is crucial for the two-phase rating algorithm. It is also required that the supervisor RBS be able to discover the location of the responsible supervised component for each atomic service for which it cannot apply a charging algorithm itself. The second requirement means that a further protocol must be implemented which allows for the workflow manager to provide the RBS with the necessary data and messages to indicate when the composed service has started and terminated. Finally, the third requirement means that the internal logic of the RBS must be able to maintain the current ‘state’ of each master composed service instance it is rating. It must also provide a means for the temporary storage of interim charge records. Taken together these enhancements represent a considerable effort in bringing the current state of the RBS in line with requirements of proposed the two-phase rating algorithm.

6.

Deploying the enhanced RBS in the Digital Business Ecosystem

Digital Business Ecosystems (DBE) [7] is a FP6 IST integrated project combining evolutionary science, business network theory and Service Oriented Architecture (SOA) concepts with the goal of propelling European ICT companies and their SME clients at the forefront of the next generation software service provision and usage. The project is developing a “Servent” architecture to facilitate the deployment, and consumption of networked services. A Servent is a term deriving from the P2P world and means a node which acts both as a server and a client. As part of the project the enhanced RBS is being deployed as part of the servent architecture. For a service to be deployable in the DBE Servent architecture there are two main requirements. First, the service must implement the service definition interface; that is, a service must be defined using an interface and then implemented through an implementing class. Second, this service implementing class must also implement the Adapter interface provided by the DBE toolkit. Figure 5, below shows how this deployment can be achieved for an existing web services implementation such as the RBS in its current form.

12

Figure 6: Deploying a pre-existing service in the DBE Servent architecture

7.

Conclusions and Future Work

Traditional network accounting systems are manually pre-configured and rigorously tested prior to the activation of a service offering; this is a time conusming and expensive process. In many cases such service offerings are realised by compositions of a number of services, sometimes provided by different providers. However, since the nature and structure of these statically-defined service compositions is negotiated in advance, it is relatively straightforward to configure accounting systems appropriately. In future environments supporting dynamic service composition this will no longer be the case. Accounting systems will have to be configured on-the-fly and it will not be possible to predict the structure of service compositions. In this scenario accounting logic relating to individual services must include incorporate information relating to how these services are to be treated when composed with other services, and accounting systems must have the ability to automatically synthesise and apply this information as services are composed and consumed. The two-phase rating process described in this paper illustrates how charging schemes can be dynamically combined to generate service usage charges that reflect business agreements between multiple providers in environments supporting dynamic service composition. The process is more complex than the stateless single phase rating processes realised by existing rating engines, thus, as we are experiencing with the RBS, requires significant redesign of rating engine architectures. The process also results in a blurring between rating and billing functionality, in that it involves the application of discounts and penalties – traditionally considered a billing activity. However, it should be noted that these discounts and penalties all relate to a single service usage session, rather then to multiple usage sessions as is generally the case with discounts calculated by billing systems. The two-phase process as described in this paper makes a number of simplifying assumptions. Most significantly, we assume that the execution of composed services always completes successfully; the process will be enhanced to address issues relating

13

to partial completion of the execution of a composed service. For example, what discounts/penalties should be applied in cases where one or more services in a composition fail to complete? Beyond this, we plan to address both the potential role of rating engines in providing service cost estimates that could be used in the service compostion process and examine issues relating to billing and payment for dynamically composed services.

References [1] IPDR.org, References, Terminology and Glossary [Online], Available: http://www.ipdr.org/public/DocumentMap/RTG3.5.htm [2005, May 30th]; [2] B. Bhushan, M. Tschichholz, E. Leray and W. Donnelly, Federated Accounting: Service Charging and Billing in a Business to Business Environment, in Proc. IFIP/IEEE Int’l Symp. on Integrated Management, 2001, pp. 107-121; [3] V. Agarwal, N. Karnik and A. Kumar, Metering and accounting for composite e-Services, in Proc. 1st IEEE Int’l Conf. on E-Commerce, 2003, pp. 35-39; [4] AlbatrOSS, Architecture for Location Based Application of Third generatio n Operation Support System [Online], Available: http://www.ist-albatross.org/ [2005, May30th]; [5] IPDR.org, Business Solution Requirements - Network Data ManagementUsage (NDM-U) For IP-Based Services [Online], Available: http://www.ipd r.org/public/DocumentMap/BSR-NDM-U3.5.0.1.pdf [2005, May 30th]; [6] J. Brazil, E. de Leastar, C. Ryan and M. Ó Foghlú, Workbook Approach to Algorithm Design and Service Accounting in a Component Orientated Environment, in Proc. IEEE Workshop on IP Operations and Management, 2002, Dallas, USA; [7] Digital Business Ecosystems (DBE), IST Project No. 507953, [Online], Available: http://www.digital-ecosystem.org/ [2005, May30th].

Author Biographies Brendan Jennings was awarded a PhD from Dublin City University in 2001 and a BEng in Electronic Engineering from Dublin City University in 1993. Since June 2003 he has been a Senior Investigator with the Telecommunications Software & Systems Group (TSSG) in Waterford Institute of Technology, Ireland. He is a lead researcher in the HEA-funded M-Zones programme, addressing issues relating to the design, configuration and management of “smart space” ubiquitous computing environments. His research interests are in the areas of accounting systems for dynamically composed services; user-centric, distributed policy-based management systems; performance management; and agent technology. He has published over twenty peer-reviewed publications in international journals and conference proceedings and has contributed to the work of standards bodies ETSI and FIPA.

14

Paul Malone has worked with the Telecommunications Software & Systems Group (TSSG) since 1998. Paul’s primary research interest is network service accounting and he completed his MSc (titled ‘Network Accounting Component Framework’) in 2001 as part of the Bandwidth 2000 project. Since then Paul has worked as a Research Assistant on several international research projects with TSSG throughout FP5 and has published approximately 15 peer-reviewed publications in that period. Currently Paul is working as TSSG’s primary researcher on the IST FP6 project, Digital Business Ecosystem, where he is making use of his considerable experience in the field of network accounting to provide enablers for SMEs to conduct business in the emerging digital ecosystem environments. Sven van der Meer received his Diplom (M.Sc. in computer science) and his Dr.-Ing. (PhD) from Technical University Berlin (TUB), Germany, in 1996 and 2003. From 1997 until 2003 he was Research Associate at the Technical University Berlin, and deputy head of the Competence Centre OKS at Fraunhofer FOKUS. He worked in several national and international projects, like 'IN/TMN integration', the TINA auxiliary project 'PCS in TINA' and the IST project AlbatrOSS. He joined TSSG in 2002 as research fellow and is currently Senior Investigator for the CIM Competence Centre. He is project leader of M-Zones (www.m-zones.org), a four year research programme developing concepts for managing smart spaces. Additionally, he is working on a number of FP6 project, such as the Celtic project Madeira, supervising postgraduate students (MSc and PhD), lectures at WIT and spends much of his time to further improve the TSSG. Current research areas are Autonomic Management, new management paradigms (such as P2P and community) and infrastructure management.

15