Ahmed Mihoob
email: a.m.mihoob@ncl.ac.uk

Carlos Molina-Jimenez

Santosh Shrivastava
email: santosh.shrivastava@ncl.ac.uk

Consumer Side Resource Accounting in the Cloud

Keywords: cloud resource consumption, storage and computational resources, resource metering and accounting models, Amazon Web Services

de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Cloud computing services made available to consumers range from providing basic computational resources such as storage and compute power (infrastructure as a service, IaaS) to sophisticate enterprise application services (software as a service SaaS) A common business model is to charge consumers on a pay-peruse basis where they periodically pay for the resources they have consumed. Needless to say that for each pay-per-use service, consumers should be provided with an unambiguous resource accounting model that precisely describes all the constituent chargeable resources of the service and how billing charges are calculated from the resource usage (resource consumption) data collected on behalf of the consumer over a given period. If the consumers have access to such resource usage data then they can use it in many interesting ways, such as, making their applications billing aware, IT budget planning, create brokering services that automate the selection of services in line with user's needs and so forth. Indeed, it is in the interest of the service providers to make resource consumption data available to consumers; incidentally all the providers that we know of do make such data accessible to their consumers in a timely fashion.

An important issue that is raised is the accountability of the resource usage data: who performs the measurement to collect the resource usage datathe provider, the consumer, a trusted third party (TTP), or some combination of them1 ? The traditional utility providers such as water, gas and electricity perform their own measurements to collect usage data using metering devices (trusted by consumers) that are deployed in the consumers premises. Cloud service providers also perform their own measurements to collect usage data, although, as yet there are no equivalent facilities of consumer-trusted metering; rather, consumers have no choice but to take whatever usage data that is made available by the provider as trustworthy. A good introduction into the underlying trust issues can be found in [START_REF] Molina-Jimenez | On the feasibility of bilaterally agreed accounting of resource consumption[END_REF].

In light of the above discussion, it is worth investigating whether it is possible for a consumer (or a TTP acting on behalf of the consumer) to independently collect all the resource usage data required for calculating billing charges. In effect, this means that a consumer (or a TTP) should be in a position to run their own metering service for measuring resource consumption. If this were possible, then consumers will be able to perform reasonableness checks on the resource usage data available from service providers as well as raise alarms when apparent discrepancies are suspected in consumption figures; furthermore, innovative charging schemes can be constructed with confidence by consumers who are themselves offering third party brokering services. In our earlier paper [START_REF] Mihoob | A case for consumer-centric resource accounting models[END_REF], we developed the notion of a Consumer-centric Resource Accounting Model for a cloud service. We say that a resource accounting model is weakly consumercentric if all the data that the model requires for calculating billing charges can be queried programmatically from the provider. Further, we say that an accounting model is strongly consumer-centric if all the data that the model requires for calculating billing charges can be collected independently by the consumer (or a TTP). Strongly consumer-centric accounting models have the desirable property of openness and transparency, since service users are in a position to verify the charges billed to them. That paper also evaluated the accounting model of Simple Storage Service, S3 from Amazon to see how well it matches the proposed notion.

This paper contributes to the prior work in three ways: (i) the evaluation work on accounting models is extended to include a compute service (Amazon Elastic Compute Cloud, EC2) and we point out a few ambiguities in the EC2 model description (Section 3); (ii) we precisely identify the causes that could lead to discrepancies between the metering data collected by the provider and the consumer, and whether the discrepancies can be resolved (Section 4); and (iii) we present ideas on how an accounting model should be constructed so as to make them strongly consumer-centric (Section 5).

Background

For resource accounting it is necessary to determine the amount of resources consumed by a given consumer (also called client and subscriber) during given time interval, for example, a billing period. Accounting systems are composed of three basic services: metering, accounting and billing. We show a consumer side accounting system in Fig. 1. We assume that resources are exposed as services through one or more service interfaces. As shown in the figure, the metering service intercepts the message traffic between the consumer application and the cloud services and extracts relevant data required for calculating resource usage (for example, the message size which would be required for calculating bandwidth usage). The metering service stores the collected data for use by the accounting service. The accounting service retrieves the metering data, computes resource consumption from the data using its accounting model and generates accounting data that is needed by the billing service to calculate the billing data.

Accounting models are provider-specific in the sense that the functionality of an accounting model is determined by the provider's policies. These policies determine how the metrics produced by his metering service are to be interpreted; for example, 1.7 GB of storage consumption can be interpreted by the provider's accounting model either as 1 or 2 GB. The accounting models of cloud providers are normally available from their web pages and in principle can be used by subscriber to perform their own resource accounting. The difficulty here for the subscriber is to extract the accounting model from their online documentation as most providers that we know of, unnecessarily blur their accounting models with metering and billing parameters. The parameters involved in accounting models depend on the type of service (SaaS, PaaS, IaaS, etc.) offered. In this paper we will examine, from the point of view of consumer side resource accounting, the accounting models of Amazons Simple Storage Service (S3) and Elastic Compute Cloud (EC2). In the following discussion, we gloss over the fine details of pricing, but concentrate on metering and accounting services.

S3 Accounting Model

An S3 space is organised as a collection of buckets which are similar to folders. A bucket can contain zero or more objects of up to 5 terabytes of data each. Both buckets and objects are identified by names (keys in Amazon terminology) chosen by the customer. S3 provides SOAP and RESTful interfaces. An S3 customer is charged for: a) storage: storage space consumed by the objects that they store in S3; b) bandwidth: network traffic generated by the operations that the customer executes against the S3 interface; and c) operations: number of operations that the customer executes against the S3 interface.

Storage: The key parameter in calculation of the storage bill is number of byte hours accounted to the customer. Byte Hours (ByteHrs) is the the number of bytes that a customer stores in their account for a given number of hours.

Amazon explains that the GB of storage billed in a month is the average storage used throughout the month. This includes all object data and metadata stored in buckets that you created under your account. We measure your usage in TimedStorage-ByteHrs, which are added up at the end of the month to generate your monthly charges. They further state that at least twice a day, we check to see how much storage is used by all your Amazon S3 buckets. The result is multiplied by the amount of time passed since the last checkpoint.

From the definition of ByteHrs it follows that to calculate their bill, a customer needs to understand 1) how their byte consumption is measured, that is, how the data and metadata that is uploaded is mapped into consumed bytes in S3; and 2) how Amazon determines the number of hours that a given piece of data was stored in S3 -this issue is directly related to the notion of a checkpoint.

Amazon explains that each object in S3 has, in addition to its data, system metadata and user metadata; furthermore it explains that the system metadata is generated and used by S3, whereas user metadata is defined and used only by the user and limited to 2 KB of size [START_REF]Amazon: Amazon simple storage service. developer guide[END_REF]. Unfortunately, Amazon does not explain how to calculate the actual storage space taken by data and metadata. To clarify the issue, we conducted a number of experiments (see [START_REF] Mihoob | A case for consumer-centric resource accounting models[END_REF]) involving uploading of a number of objects of different names, data and user metadata into an equal number of empty buckets.

Three conclusions can be drawn from these experiments: first, the mapping between bytes uploaded (as measured by intercepting upload requests) and bytes stored in S3 correspond one to one; second, the storage space occupied by system metadata is the sum of the lengths (in Bytes) of object and bucket names and incur storage consumption; third, user metadata does not impact storage consumption. In summary, for a given uploaded object, the consumer can accurately measure the total number of bytes that will be used for calculating ByteHrs.

Next, we need to measure the 'Hrs' of 'ByteHrs'. As stated earlier, Amazon states that at least twice a day they check the amount of storage consumed by a customer. However, Amazon does not stipulate exactly when the checkpoints take place.

To clarify the situation, we conducted a number of experiments that consisted in uploading to and deleting files from S3 and studying the Usage Reports of our account to detect when the impact of the PUT and DELETE operations were accounted by Amazon. Our findings are summarised in Fig. 2. It seems that, currently, Amazon does not actually check customers' storage consumption twice a day as they specify in their Calculating Your Bill document, but only once. From our observations, it emerged that the time of the checkpoint is decided randomly by Amazon within the 00:00:00Z and 23:59:59Z time interval2 .

In the figure, CP stands for checkpoint, thus CP 30 : 2GB indicate that CP 30 was conducted on the 30th day of the month at the time specified by the arrow and reported that at that time the customer had 2 GB stored in S3. SC stands for Storage Consumption and is explained below. As shown in the figure, Amazon uses the results produced by a checkpoint of a given day, to account the customer for the 24 hrs of that day, regardless of the operations that the customer might perform during the time left between the checkpoint and the 23:59:59Z hours of the day. For example, the storage consumption for the 30th will be taken as 2×24 = 48 GBHrs; where 2 represents the 2GB that the customer uploaded on the 30th and 24 represents the 24 hrs of the day.

Bandwidth: Amazon charges for the network data transferred from the customer to S3 ('DataTransfer-In', the request message of an operation) and the network data transferred from S3 to the customer (the corresponding response message, 'DataTransfer-Out'). It is however not clear from the available information how the size of of the message is calculated. We therefore conducted several experiments involving uploading, downloading, deleting etc. of objects using both RESTful and SOAP interfaces and compared the information extracted from the intercepted messages with the information available from Amazon usage reports. It turns out that for RESTful operations, only the size of the object (in DataTransfer-In for PUT, and DataTransfer-Out for GET) is taken into account and system and user metadata is not part of the overhead, whereas for SOAP operations, the total size of the message is taken into account.

Operations: It is straightforward for a consumer to count the type and number of operations performed on S3. We note that an operation might fail to complete successfully. The error response in general contains information that helps identify the party responsible for the failure: the customer or the S3 infrastructure. For example, NoSuckBucket errors are caused by the customer when they try to upload a file into a non-existent bucket; whereas an InternalError code indicates that S3 is experiencing internal problems. Our understanding is that the consumer is charged for an operation, whether the operation succeeded or not.

EC2 Accounting Model

EC2 is a computation service offered by Amazon as an IaaS [4]. The service offers raw virtual CPUs (also called a Virtual Machine or VM) to subscribers. A subscriber is granted administrative privileges over his VM, that he can exercice by means of sending remote comands to the Amazon Cloud from his desktop computer. For example, he is expected to configure, launch, stop, re-launch, terminate, backup, etc. his VM. In return, the subscriber is free to choose the operating system (eg Windows or Linux) and applications to run. In EC2 terminology, a running virtual CPU is called an instance whereas the frozen bundle of software on disk that contains the libraries, applications and initial configuration settings that are used to launch an instance is called the Amazon Machine Image (AMI).

Currently, Amazon offers six types of instances that differ from each other in four initial configuration parameters that cannot be changed at running time: amount of EC2 compute units that it delivers, size of their memory and local storage (also called ephemeral and instance storage) and the type of platform (32 or 64 bits). An EC2 compute unit is an Amazon unit and is defined as the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor. Thus Amazon offer small, large, extra large and other types of instances. For example, the default instance type is the Small Instance and is a 32 bit platform that delivers 1 EC2 compute unit and provided with 1.7 GB of memory and 160 GB of local storage. These types of instances are offered to subscribers under several billing models: on-demand instances, reserved instances and spot instances. In our discussion we will focus on on-demand instances.

Under the on-demand billing model, Amazon defines the unit of consumption of an instance as the instance hour (instanceHrs). Currently, the cost of an instance hour of a small instance running Linux or Windows, is, respectively, 9.5 and 12 cents. On top of charges for instance hours, instance subscribers normally incur additional charges for data tranfer that the instances generates (Data Transfer In and Data Transfer Out) and for addtional infrastructure that the instance might need such as disk storage, IP addresses, monitoring facilities and others. As these additional charges are accounted and billed separately, we will leave them out of our discussion and focus only on instance hours charges.

The figures above imply that if a subscriber accrues 10 instanceHrs of a small instance consumption, running Linux, during a month, he will incur a charge of 95 cents at the end of the month.

In principle, the pricing tables publicly available from Amazon web pages should allow a subscriber to independently conduct his own accounting of EC2 consumption. In the absence of a well defined accounting model this is not a trivial exercise.

Insights into the EC2 accounting model are spread over several on-line documents from Amazon. Some insight into the definition of instance hour is provided in the Amazon EC2 Pricing document [START_REF]Amazon ec2 pricing[END_REF] (see just below the table of On-demand Instances) where it is stated that Pricing is per instance-hour consumed for each instance, from the time an instance is launched until it is terminated. Each partial instance-hour consumed will be billed as a full hour. This statement suggests that once an instance is launched it will incur at least an instance hours of consumption. For example, if the instance runs continuouly for 5 minutes, it will incur 1 instanceHrs; likewise, if the instance runs continuously for 90 minutes, it will incur 2 instanceHrs.

The problem with this definition is that it does not clarify when an instance is considered to be launched and terminated. Additional information about this issue is provided in the Billing section of FAQs [START_REF]Amazon ec2 faqs[END_REF], Paying for What You Use of the Amazon Elastic Compute (Amazon EC2) document [4] and in the How You're Charged section of the User Guide [START_REF]Amazon: Amazon elastic compute cloud user guide (api version[END_REF]. For example, in [4] it is stated that Each instance will store its actual launch time. Thereafter, each instance will charge for its hours of execution at the beginning of each hour relative to the time it launched.

From information extracted from the documents cited above it is clear that Amazon starts and stops counting instance hours as the instance is driven by the subscriber, through different states. Also, it is clear that Amazon instance hours are accrued from the execution of one or more individual sessions executed by the subscriber during the billing period. Within this context, a session starts and terminates when the subscriber launches and terminates, respectively, an instance.

Session-based accounting models for resources that involve several events and states that incur different consumptions, are conveniently described by Finite State Machines (FSMs). We will use a FSM to describe EC2 accounting model.

States of an instance session

The states that an instance can reach during a session depend on the type of memory used by the AMI to store its boot (also called root) device. Currently, Amazon supports S3-backed and EBS-backed instances. EBS stands for Elastic Block Store and is a persistent storage that can be attached to an instance. The subscriber chooses between S3 or EBS backed instances at AMI creation time.

Unfortunatelly, the states that an instance can reach during a session are not well documented by Amazon. Yet after a careful examination of Amazon's online documentation we managed to build the FSM shown in Fig. 3-a). The FSM of an Amazon instance includes two types of states: permanent and transient states. Permanent states (represented by large circles, e.g. running) can be remotely manipulated by commands issued by the subscriber; once the FSM reaches a permanent state, it remains there until the subscribers issues a command to force the FSM to progress to another state. Transient states (represented by small circles, e.g. stopping) are states that the FSM visits temporarily as it progresses from a permanent state into another. The subscriber has no control over the time spent in a transient state; this is why there are no labels on the outgoing arrows of these states.

We have labeled the transitions of the FSM with event/action notations. The event is the cause of the transition whereas the action represents the set (possibly empty) of operations that Amazon executes when the event occurs, to count the numbers of instance hours consumed by the instance.

There are two types of events: subscriber's and internal to the FSM events. The subscriber's events are the comands (launch, application commands, reboot, stop and terminate) that the subscribers issues to operate his instance; likewise, internal events are events that occur independently from the subscriber's commands, namely, timer = 60min and failure.

AMI configured: is the initial state. It is reached when the subscriber sucessfully configures his AMI so that it is ready to be launched. running: is the state where the instance can perform useful computation for the subscriber, for example, it can respond to application commands issued by the subscriber. terminated: is the final state and represents the end of the life cycle of the instance. Once this state is reached the instance is destroyed. To perform additional computation after entering this state the subscriber needs to configure another AMI. The terminated state is reached when the subscribed issues the terminate command, the instance fails when it is in running state or the instance fails to reach running state. shuttingdown: is reached when the subscriber issues the terminate command. stopped: this state is supported only EBS-backed instances (S3-backed instances cannot be stopped) and is reached when the user issues stop command, say for example, to perform backup duties. rebooting: is reached when the subscriber issues the reboot command.

States and and instance hours: In the figure, N instHrs is used to count the number of instance hours consumed by an instance during a single session. The number of instance hours consumed by an instance is determined by the integer value stored in N instHrs when the instance reaches the terminated state. timer is Amazon's timer to count 60 minutes intervals; it can be set to zero (timer = 0) and started (starttimer).

In the FSM, the charging operations are executed as suggested by the Amazon's on line documentation. For example, in Paying for What You Use Section of [4], Amazon states that the beginning of an instance hour is relative to the launch time. Consequently, the FSM sets N instHrs = 1 when the subscriber executes a launch command from the AMI configured state. At the same time, timer is set to zero and started. N instHrs = 1 indicates that once a subscriber executes a launch command, he will incur at least one instance hour. If the subscriber leaves his instance in the running state for 60 minutes (timer = 60min) the FSM increments N instHrs by one, sets the timer to zero and starts it again. From running state the timer is set to zero when the subscriber decides to terminate his instance (terminate command) or when the instance fails (failure event). Although Amazon's documentation does not discuss it, we believe that the possibility of an instance not reaching the running state cannot be ignore, therefore we have included a transition from pending to terminated state; the FSM sets the timer to zero when this abnormal event occurs.

As explained in Basics of Amazon ESB-Backed AMIs and Instances and How You're Charged of [START_REF]Amazon: Amazon elastic compute cloud user guide (api version[END_REF], a running ESB-backed instance can be stopped by the subscriber by means of the stop command and drive it to the stopped state. As indicated by timer = 0 operation executed when the subscribed issues a stop command, an instance in stopped state incurs no instance hours. However, though it is not shown in the figure as this is a different issue, Amazon charges for EBS storage and other addtional services related to the stopped instance. The subscriber can drive an instance from the stopped to the terminated state. Alternatively he can re-launch his instance. In fact, the subscriber can launch, stop and launch his instance as many times as he needs to. However, as indicated by the N instHrs + + , timer = 0 and starttimer operations over the arrow, every transition from stopped to pending state accrues an instance hours of consumption, irrespectively of the time elapsed between each pair of consecutive launch commands.

Experiments with Amazon instances:

To verify that the accounting model described by the FSM of Fig. 3-a) matches Amazon's description, we (as subscribers) conducted a series of practical experiments. In particular, our aim was to verify how the number of instance hours is counted by Amazon.

The experiments involved 1) configuration of different AMIs; 2) launch of instances; 3) execution of remote commands to drive the instances through the different states shown in the FSM. For example, we configured AMIs, launched and run them for periods of different lengths and terminated them. Likewise, we launched instances and terminated them as soon as they reached the running state.

To calculate the number of instance hours consumed by the instances, we recorded the time of execution of the remote commands launch, stop, terminate and reboot, and the time of reaching both transient and permanent states. For comparison, we collected data (start and end time of an instance hour, and number of instance hours consumed) from Amazon EC2 usage report.

A comparison of data collected from our experiments against Amazon's data from their usage report reveals that currently, the beginning of an instance hour is not the execution time of the subscriber's launch command, as documented by Amazon, but the time when the instance reaches the running state. These findings imply that the current accounting model currently in use is the one described by the FSM of Fig. 3-b). As shown in the figure, the N instHrs is incremented when the instance reaches the running state.

Potential Causes of Discrepancies

Storage

Since, for the calculation of ByteHrs, the time of the checkpoint is decided randomly by Amazon within the 00:00:00Z and 23:59:59Z time interval, the time used at the consumer's side need not match that at the provider's side: a potential cause for discrepancy. This is illustrated with the help of Fig. 4. The figure shows the execution time of four PUT and one DEL operations executed by an S3 consumer during the last two days of March. The first day of April is also shown for completeness. For simplicity, the figure assumes that the earliest PUT operation is the very first executed by the consumer after opening his S3 account. The figure also shows the specific points in time when checkpoints are conducted independently by two parties, namely, Amazon and a consumer. Thus, CP and cp represent, respectively, Amazon's and the consumer's checkpoints; the Giga Bytes shown next to CP and cp indicate the storage consumption detected by the checkpoint. For example, on the 30th, Amazon conducted its checkpoint about five in the morning and detected that, at that time, the customer had 6 GB stored (CP 30 : 6GB). On the same day, the consumer conducted his checkpoint just after midday and detected that, at that time, he had 6 GB stored (cp 30 : 6GB). SC and sc represent, respectively, the storage consumption for the month of March, calculated by Amazon and consumer, based on their checkpoints.

The figure demonstrates that the storage consumption calculated by Amazon and consumer might differ significantly depending on the number and nature of the operations conducted within the time interval determined by the two parties' checkpoints, for example, within CP 31 and cp 31 .

Scenario a) shows an ideal situation where no consumer's operations are executed within the pair of checkpoints conducted on the 30th or 31st. The result is that both parties calculate equal storage consumptions. In contrast, b) shows a worse-case scenario where the DEL operation is missed by CP 30 and counted by cp 30 and the PUT operation is missed by cp 31 and counted by CP 31 ; the result of this is that Amazon and the consumer, calculate SC and sc, respectively, as 312 GB and 144 GB.

Ideally, Amazon's checkpoint times should be made known to consumers to prevent any such errors. Providing this information for upcoming checkpoints is perhaps not a sensible option for a storage provider, as the information could be 'misused' by a consumer by placing deletes and puts around the checkpoints in a manner that artificially reduces the consumption figures. An alternative would be to make the times of past checkpoints available (e.g., by releasing them the next day).

Impact of network and operation latencies: In the previous discussion concerning calculation of ByteHrs (illustrated using Fig. 4), we have implicitly assumed that the execution of a PUT (respectively a DELETE) operation is an atomic event whose time of occurrence is either less or greater than the checkpoint time (i.e., the operation happens either before or after the checkpoint). This allowed us to say that if the checkpoint time used at the provider is known to the consumer, then the consumer can match the ByteHrs figures of the provider. However, this assumption is over simplifying the distributed nature of the PUT (respectively a DELETE) operation. In Fig. 5 we explicitly show network and operation execution latencies for a given operation, say PUT; also, i, j, k and l are provider side checkpoint times used for illustration. Assume that at the provider side, only the completed operations are taken into account for the calculation of ByteHrs; so a checkpoint taken at time i or j will not include the PUT operation (PUT has not yet completed), whereas a checkpoint taken a time k or l will. What happens at the consumer side will depend on which event (sending of the request or reception of the response) is taken to represent the occurrence of PUT. If the timestamp of the request message (PUT) is regarded as the time of occurrence of PUT, then the consumer side ByteHrs calculation for a checkpoint at time i or j will include the PUT operation, a discrepancy since the provider did not! On the other hand, if the timestamp of the response message is regarded as the time of occurrence of PUT, then a checkpoint at time k will not include the PUT operation (whereas the provider has), again a discrepancy. In short, for the operations that occur 'sufficiently close' to the checkpoint time, there is no guarantee that they get ordered identically at both the sides with respect to the checkpoint time. Operations: Earlier we stated that it is straightforward for a consumer to count the type and number of operations performed on S3. There is a potential for discrepancy caused by network latency: operations that are invoked 'sufficiently close' to the end of an accounting period (say i) and counted by the consumer for that period, might get counted as performed in the next period (say j) by the provider if due to the latency, these invocation messages arrive in period j. This will lead to the accumulated charges for the two period not being the same. This is actually not an issue, as the Amazon uses the timestamp of the invocation message for resolution, so the consumer can match the provider's figure.

One likely source of difficulty about the charges for operations is determining the liable party for failed operations. Currently, this decision is taken unilaterally by Amazon. In this regard, we anticipate two potential sources of conflicts: DNS and propagation delays. As explained by Amazon, some requests might fail and produce a Temporary Redirect (HTTP code 307 error) due to temporary routing errors which are caused by the use of alternative DNS names and request redirection techniques [START_REF] Murty | Programming Amazon Web Services[END_REF]. Amazon's advice is to design applications that can handle redirect errors, for example, by resending a request after receiving a 307 code(see [START_REF]Amazon: Amazon simple storage service. developer guide[END_REF], Request Routing section). Strictly speaking these errors are not caused by the customer as the 307 code suggests. It is not clear to us who bears the cost of the re-tried operations.

EC2

The mismatch between Amazon's documented accounting model and the one currently in use (Fig. 3-a and b, respectively) might result in discrepances between the subscriber's and Amazon's calculations of instance hours. For example, imagine that it takes five minutes to reach the running state. Now imagine that the subscriber launches an instance, leaves it running for 57 minutes and then terminates it. The subscriber's N instHours will be equal to two: N instHrs = 1 at launch time and then N instHrs is incremented when timer = 60min. In contrast, to the subscriber's satisfaction, Amazon's usage records will show only one instance hour of consumption. One can argue that this discrepancy is not of the subscriber's concern since, economically, it always favours him.

More challenging and closer to the subscriber's concern are discrepancies caused by failures. Amazon's documentation does not stipulates how instances that fail accrue instance hours. For example, examine Fig. 3-a) and imagine that an instance suddenly crashes after spending 2 hrs and 15 min in running state. It is not clear to us whether Amazon will charge for the last 15 min of the execution as a whole instance hour. As a second example, imagine that after being launched either from AMI configured or stopped states, an instance progresses to pending state and from there, due to a failure, to terminated. It is not clear to us if Amazon will charge for the last instance hour counted by N instHrs.

We believe that, apart from these omissions about failure situations, the accounting model of Fig. 3-a) can be implemented and used by the subscriber to produce accurate accounting. A salient feature of this model is that all the events (launch, stop and terminate) that impact the N instHrs counter are generated by subscriber. The only exeception if the timer = 60min event, but that can be visible to the subscriber if he synchronises his clock to UTC time.

The accounting model that Amazon actually uses (Fig. 3-b) is not impacted by failures of instances to reach running state because in this model, N insHrs is incremented when the instance reaches running state. However, this model is harder for the subscriber to implement since the event that causes the instance to progress from pending to running state is not under the subscriber's control.

Related Work

An architecture for accounting and billing for resources consumed in a federated Grid infrastructure is suggested in [START_REF] Elmroth | Accounting and billing for federated cloud infrastructures[END_REF]. The paper provides a valuable insight into the requirements (resource re-deployment, SLA awareness, pre-paid and postpaid billing, standardised records and others) that accounting and billing services should meet. In [START_REF] Bhushan | Federated accounting: Service charging and billing in a business-to-business environment[END_REF], the author discuss similar requirements for accounting and billing services, but within the context of federated network of telecommunication providers. Both papers overlook the need to provide consumers with means of performing consumer-side accounting. A detailed discussion of an accounting system similar to the one shown in Fig. 1 but aimed at telecommunication services is provided in [START_REF] De Leastar | Flexible multi-service telecommunications accounting system[END_REF].

Accounting models are fundamental to subscribers interested in planning for minimisation of expenditures on cloud resources. The questions raised are what workload to outsource, to which provider, what resources to rent, when, and so on. Examples of research results in this direction are reported in [START_REF] Wang | Distributed systems meet economics: Pricing in the cloud[END_REF][START_REF] Den Bossche | Cost-optimal scheduling in hybrid IaaS clouds for deadline constrained workloads[END_REF]. In [START_REF] Den Bossche | Cost-optimal scheduling in hybrid IaaS clouds for deadline constrained workloads[END_REF] the authors discuss how an accouting service deployed within an organisation can be used to control expenditures on public cloud resources; their accounting service relies on data downloaded from the cloud provider instead of calculating it locally.

In [START_REF] Deelman | The cost of doing science on the cloud: The montage example[END_REF], the authors take Amazon cloud as an example of cloud provider and estimate the performance and monetary-cost to compute a data-intensive (terabytes) workflow that requires hours of CPU time. The study is analytical (as opposite to experimental) and based on the authors' accouting model. For instance, to produce actual CPU-hours, they ignore the granularity of Amazon instance hours and assume CPU seconds of computation. This work stresses the relevance of accounting models.

Concluding Remarks

We investigated whether it is possible for a consumer (or a TTP acting on behalf of the consumer) to independently collect, for a given cloud service, all the resource usage data required for calculating billing charges. We examined two main IaaS services: storage and compute from Amazon; our investigation revealed the causes that could lead to discrepancies between the metering data collected by the the consumer not matching that of the provider. Essentially these causes can be classed into three categories discussed below.

1. Incompleteness and ambiguities: We pointed out several cases where an accounting model specification was ambiguous or not complete. For example, regarding bandwidth consumption, it is not clear from the available information what constitutes the size of of a message. It is only through experiments we worked out that for RESTful operations, only the size of the object is taken into account and system and user metadata is not part of the message size, whereas for SOAP operations, the total size of the message is taken into account. Failure handling is another area where there is lack of information and/or clarity: for example, concerning EC2, it is not clear how instances that fail accrue instance hours. 2. Unobservable events: If an accounting model uses one or more events that impact resource consumption, but these events are not observable to (or their occurrence cannot be deduced accurately by) the consumer, then the data collected at the consumer side could differ from the that of the provider. Calculation of storage consumption in S3 (ByteHrs) is a good example: here, the checkpoint event is not observable. 3. Differences in the measurement process: Difference can arise if the two sides use different techniques for data collection. Calculation of BytHrs again serves as a good example. We expect that for a checkpoint, the provider will directly measure the storage space actually occupied, whereas, for a given checkpoint time , the consumer will mimic the process by adding (for PUT) and subtracting (for DELETE) to calculate the space, and as we discussed with respect to Fig. 5, discrepancies are possible.

Issues raised by clauses 1 and 2 can be directly addressed by the providers. A provider should evaluate their accounting models by performing consumer side accounting experiments to reveal any shortcommings. In particular, we recommend that for services that go through several state transitions (like EC2), providers should explicitly give FSM based descriptions, and ensure, as much as possible, that their models do not rely on unobservable (to consumer) events for billing charge calculations. On the whole, for IaaS services, consumer side accounting appears quite feasible. Whether this applies to PaaS and SaaS remains to be seen. Any discrepancies that get introduced unintentionally (e.g., due to non identical checkpoint times) can be resolved by consumers by careful examination of corresponding resource usage data from providers. Those that cannot be resolved would indicate errors on the side of consumers and/or providers leading to disputes.

Fig. 1 .

 1 Fig. 1. Consumer side resource accounting system.

Fig. 2 .

 2 Fig. 2. Amazon's checkpoints.

Fig. 3 .

 3 Fig. 3. Session of an Amazon instance represented as FSM.

Fig. 4 .

 4 Fig. 4. Impact of checkpoints.

Fig. 5 .

 5 Fig. 5. Network and operation latencies.

A note on terminology: 'accountability' refers to concepts such as responsibility, answerability, trustworthiness; not to be confused with 'resource accounting' that refers to the process concerned with calculating financial charges.

S3 servers are synchronised to the Universal Time Coordinated (UTC) which is also known as the Zulu Time (Z time) and in practice equivalent to the Greenwich Mean Time (GMT).


Vladimirs Kotovs
email: vladimirs.kotovs@rtu.lv

Andrejs Lesovskis
email: andrejs.lesovskis@rtu.lv

Leonids Novickis
email: leonids.novickis@rtu.lv

Towards Reuse-Oriented and Web-Based Collaborative Framework for e-Business Providers

Keywords: e-business, software reuse, web-based collaboration

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Today e-business has emerged as a mainstream way to facilitate business transactions around the world. Web and Internet electronic business technologies promise to transform every aspect of the way companies conduct business and compete [START_REF] Westermeier | E-Business: The E-Business Legal Survival Kit[END_REF]. The Internet has fundamentally changed the economics of business transactions and provided new and different ways of conducting business. However, e-business segment of the particular domain a company is operating in is usually characterised by a very high competition. Large enterprises with their international networks have significant advantages over small and medium-sized companies. For individual small and medium enterprises (SME) it is difficult to solve the problems alone; however, by co-operation and efficient utilization of knowledge and resources, they can succeed and keep relatively big segment of the market.

The technologies enable people to communicate in new ways, provide new business models, permit businesses to operate more efficiently and take advantage of the new global network economy. Companies have come to realize that if they are going to respond rapidly and effectively to todays volatile marketplace, they need to do more than web-enable discrete systems, processes or business units. They need to pull together existing systems and integrate them securely with their core business activities [START_REF] Westermeier | E-Business: The E-Business Legal Survival Kit[END_REF].

At the same time in the current situation of financial crisis it is extremely important for applied technologies to provide some economic and organizational benefits by reducing development and operating costs, and by efficient utilization of development knowledge and corporate expertise. The need in systematic approach and effective software engineering methods, which allow reusing experience to address recurring problems successfully, is obvious and important for e-business providers.

With more than 40-year history reuse is recognized as an important mechanism to improve software quality and development productivity [START_REF] Kotov | Forty years of software reuse[END_REF]. Today, we are just at the start of this challenge but we believe that the synergy of web-based and reuse-oriented methods for software solutions may create a new platform of e-business opportunities.

The paper presents the review of the ongoing joint research activities related to the introduction of systematic software reuse and web-based collaboration in the enterprise paying special attention to the needs and the problems of e-business providers. The following sections discuss current limitations and expected benefits of the research. It is followed by the review of proposed reuseoriented and web-based collaborative frameworks. Finally, the conclusions are made and future work is discussed in the last section.

Expected benefits and the main drivers of the research

The following bottlenecks and limitations have been identified as the main drivers for our joint research activities:

• The existing IT solutions usually support separate stages of business processes and are not focused on integrated web-based solutions that provide an opportunity to manage core business activities within the whole company or across the entire value chain from customers to suppliers.

• Intermodal collaboration among e-business service providers usually isn't effectively organized.

• Existing efforts to attain the main objective of software reuse in the ebusiness domain rendered some successful stories, however, to benefit in more systematic and repeatable way, additional research is needed.

• Reuse requires up-front investments in infrastructure, methodology, training and tools without pay-offs being realized immediately and cannot be widely achieved in organizations without support of top-level management. However, reuse will only succeed, if it makes good business sense, and it will only be chosen, if a good case can be made that it is the best alternative choice for the use of capital [START_REF] Frakes | Software Reuse Research: Status and Future[END_REF].

• Reusing of large-scale system components is a problem too hard to be solved in general way. It is more effective when systematically applied in the context of families of related systems and thus is domain-dependent.

The expected advances and benefits of the research are the following:

• The reuse-oriented framework for organizations that are moving towards an effective reuse program composed of different aspects of software reuse and related practices. The final goal is to ingrain reuse into an organizations entire software production process [START_REF] Frakes | Software Reuse and Domain Engineering[END_REF]. A formalized process increases the chance that the project success can be repeated, facilitates adherence to the established best practices, standardization of practices across multiple projects, and helps less-expert developers to succeed via reliance on a standard process. Additionally, the framework expected to define effective measuring of economic benefits of the software reuse and development costs, where operational and strategic benefits are defined and quantified within the context of broader business strategy. However, each organization should analyse its own needs, define the key benefits, identify and remove impediments, and manage risks [START_REF] Frakes | Success Factors of Systematic Reuse[END_REF].

• The methodology for Internet-based Collaborative Framework (ICF) development is based on advanced web technologies. ICF provides the adaptation mechanism to distinct between different target groups (technology supplier, technology receiver, technology transfer facilitator). ICF is also expected to provide easy commercialization and adaptation of technology transfer process (Fig. 1). Software reuse is the process of creating software systems from existing software rather than building them from scratch, whereby an organization defines a set of systematic operating procedures to specify, produce, classify, retrieve, and adapt software artefacts with the purpose of using them in its development activities [START_REF] Mili | Reuse-based Software Engineering: Techniques, Organization, and Measurement[END_REF], so that similarities in requirements and/or architecture between applications can be exploited to achieve substantial benefits [START_REF] Ezran | Practical Software Reuse[END_REF]. Our retrospective analysis of the origins and main contributions in the research area performed in [START_REF] Kotov | Forty years of software reuse[END_REF] outlines that software reuse is multidisciplinary and has deep and complex interactions with many areas of computer science. Table 1 consolidates the main benefits from [START_REF] Sametinger | Software Engineering with Reusable Components[END_REF] that can be achieved by the organizations with the maximization of the reuse level.

Table 1. Main benefits of reuse

Benefits of reuse Description

Gains in quality Quality of particular component could be improved because of accumulated error corrections Gains in reliability The use of a component in several systems increases the chance of errors to be detected and improves confidence in that component Gains in productivity Productivity could be achieved due to less design and code to be developed Gains in performance Extensive reuse can be worth the effort invested in optimizations, that may yield better performance of a reused component Reduction of maintenance costs Fewer defects and reduction of maintenance costs can be expected when proven quality components have been used Reduction of product time to market By using reusable artifacts organizations could reduce the product time to market which influences the success or failure of a software product Rapid prototyping Reusable components can provide an effective basis for quick building of a prototype of a software system Directions and components for reuse-oriented framework comply with the following main conclusions that we have obtained through the survey [START_REF] Kotov | Reuse In Software Development Organizations In Latvia[END_REF] involving software organizations in Baltic regions, whose responses were analysed and used to relate the characteristics of organizations with their reuse experience:

• 72% participants claimed to succeed in projects by the means of software reuse in their organization, and small and medium software organizations presented higher reuse success rates than organizations of a large size.

• Organizations should focus on the development of product families if applicable in the operating business area.

• Attention should be spent on the introduction of process-driven systematic reuse in the organization.

• Organizations should consider using repository for storing and retrieving reusable assets, and a configuration management process should guarantee proper evolution of these assets.

The overall structure of the considered reuse-oriented framework is organized in economic (A), organizational (B), and process (C) dimensions as outlined on Figure 2. (A) From the economic perspective implementing a reuse initiative in a corporate environment requires a decision about when and where capital investment for software reuse is to be made, and whether it will be proactive or reactive [START_REF] Frakes | Software Reuse Research: Status and Future[END_REF].

The measuring of economic benefits of the software reuse and development costs should be aligned with the following main principles from [START_REF] Favaro | Value Based Software Reuse Investment[END_REF]:

• Economic value maximization drives reuse investment strategies for the business

• Strategy drives selection of reuse investments that are actively structured to maximize embedded strategic options.

Economic aspects of software reuse are divided into the following broad classes by [START_REF] Mili | Reuse-based Software Engineering: Techniques, Organization, and Measurement[END_REF]:

-Metrics, which reflect attributes that increase the market value of an asset -Reuse cost estimation techniques and return-on-investment (ROI) models to quantify reuse related decisions.

(B) Several approaches exist for establishing a reuse program from the organizational perspective:

• Centralized, with an organizational unit dedicated to developing, distributing, maintaining, and providing training on reusable assets.

• Distributed asset development, where reuse is implemented collaboratively by projects in the same product line.

Reuse environment on the organizational level assumes development of -Managerial infrastructure in the form of a set of functions, responsibilities, reporting requirements, and reward, which are required to ensure operation of reuse processes -Technological infrastructure that includes a configuration management and quality assurance functions to support reuse operations, as well as enforcement of testing, verification and asset certification standards.

(C) Process-driven means that the software development is done in accordance with well defined processes that are enforced through management policies. A software process could be defined as a set of activities that lead to the production of a software product [START_REF] Sommerville | Software engineering. 6th[END_REF], and it is important in order to ensure efficiency, reproducibility, homogeneity, and predictable time and effort constraints. As it was noted already, a key concept of systematic reuse is the domain, which may be defined as an application area or, more formally, a set of systems that possess similar functionality and share design decisions. By domain-specific reuse we assume, that the reusable assets, the development processes, and the supporting technologies are appropriate to the application domain for which the software is being developed. It is common to identify three main stakeholders in the process of software reuse within an organization: corporate management, domain engineering and application engineering teams. By reviewing the tasks of each of these stakeholders, the following top-level reuse related activities can be identified:

• Asset production -identification, development and classification of reusable artefacts

• Asset usage -locating and evaluating assets, and achieving their actual reuse by integrating them into applications being developed

• Asset management -asset storage, repository management, and asset dissemination

• Maintenance and support -support for asset usage, methodological support, and corrective and evolutionary maintenance of assets

• Reuse management -introducing and monitoring reuse within a company or department.

To support reuse, software processes have to consider two facets: developing for reuse and developing with reuse. As a result comparing to conventional monolithic set of tasks organizations are responsible for providing and maintaining software systems, software reuse introduces a differentiation between the tasks related to the production of reusable assets and the tasks related to the production of end-user applications [START_REF] Ezran | Practical Software Reuse[END_REF]. Such two-life-cycle approach with generalized activities schematically displayed on Figure 3 is commonly referred as domain and application engineering, which address development for reuse and development with reuse respectively. From the technical point of view the e-business provider development within the proposed framework should rely on the best practices and appropriate supporting methodologies facilitating global visibility, integration and collaboration as noted in section 1. The Internet-based collaborative framework (ICF) as discussed in the next section aimed to provide a facade for several advanced IT solutions in order to support e-business.

Internet-Based collaborative framework for e-business providers

E-business denotes using computer-mediated networks to perform a wide range of commercial transactions, to automate and transform business processes at the firm level, and to manage more effectively value chains across firms. In addition to e-commerce, customer service and support applications, e-business can include human-resource functions, sales-force automation, supply-chain management and other applications to automate firms' central internal processes [START_REF]The Digital Economy in Canada: The e-Business Environment[END_REF].

The online environment that supports dynamic e-business should provide the following capabilities:

• Open application interfaces that provide interaction between business partners, service providers, and other participants;

• Open standards that define business transaction processes and would improve automation of business to business (B2B) interactions;

• Internet-based communication methods with opportunity to extend to other public or private systems;

• Easy adaptation to market condition changes.

Web services enable many of these key prerequisites for dynamic e-business solutions. They define a standard way to describe and invoke a Web service interface so that the business application can easily connect to it. In the report entitled Executive Survey: SOA Implementation Satisfaction, Hurwitz & Associates analysts point out that the top reasons for SOA adoption include the expectation of greater reuse in existing and newly-built Web services, business flexibility, ease of integration and speed of integration with nearly 90% of respondents pointing to service reuse as their number one concern [START_REF] Baroudi | Executive Survey: SOA Implementation Satisfaction[END_REF].

According to World Wide Web Consortium (W3C), there are two major classes of Web services:

• REST-compliant Web services, in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of "stateless" operations; and

• Arbitrary Web services, in which the service may expose an arbitrary set of operations (most of the SOAP-based Web services) [START_REF]Web Services Architecture[END_REF].

REST (Representation State Transfer) provides four familiar operations GET, POST, PUT, and DELETE of the HTTP standard, and make the resource addressing handle the variability. SOAP (Simple Object Access Protocol), on the other hand, permits quite a complex set of XML formatted commands and data transmission options. In contrast with REST which requires HTTP, SOAP messages can be moved by any transport method which can handle Unicode text. But HTTP transport is preferred by many developers because it is more familiar and SOAP with HTTP can tunnel easily over existing firewalls and proxies, without modifications to the SOAP protocol, and can use the existing infrastructure.

Technologies like SOA, Web services, Semantic Interoperable Services, XML, SOAP, and AJAX Web development techniques can be used as a technological platform for the integration. Using these technologies together with the existing enterprise web platforms and portal frameworks (like Liferay, GateIn, Web-Sphere Portal, JetSpeed, etc), it is possible to design the integrated portals that will provide seamless integration of the various business-related services and data sources. For instance, separate portals that support different logistics business processes along the selected freight route (www.elogmar-m.org, ww.containeronlineshop.de, www.e-56.com.cn) are united into one framework with a single entry point (Fig. 4) [START_REF] Bluemel | IT&T Solutions in Logistics and Maritime Applications[END_REF].

An enterprise portal, built with a robust portal product, provides an off-theshelf framework for developing and deploying service-oriented applications. It can serve as a ready-made Web services consumer platform, and enables you to build composite applications, deploy syndicated content from other portals through remote portlets, replace/augment legacy interfacing applications, create common views of data, and facilitate access by mobile and wireless devices [START_REF] Phifer | A Portal May Be Your First Step to Leverage SOA[END_REF].

Most of the mentioned above portal frameworks also have personalization features. Personalization provides end-users with an opportunity to customize their version of a portal; thereby, greatly improving end-user performance and satisfaction. Using personalization mechanism, portal administrators can define specific groups which may represent portal users real-life roles (operator, manager, CEO, etc). Depending on their roles, users will have access to the features and content designed for their group.

One of the goals in our test case is the integration of eLogmar portal services with a newly designed portal. We are using NuSOAP Toolkit in eLogmar portal to provide SOAP-based access to system functionality (shipping lines services, freight cost calculation, etc).

Conclusion

The need in systematic approach and effective software engineering methods that facilitate global visibility and collaboration and allow reusing experience to address recurring problems successfully, is obvious and extremely important for e-business. The study presents the foundation of the framework for organizations moving towards a reuse program that is organized considering economic, organizational and process aspects of software reuse. Although the work might be still considered to be in its early stages, the study defines the basis, the components and directions for further research activities. Based on our experience in portal development and integration projects, we are currently working on consolidation of best practices and general recomendations for e-business providers. Another important issue concerns maturity of reuse processes without gaps in reuse activities covering steps of domain engineering, domain analysis, design and implementation. The planned future work is related to the formalization of the processual dimension of the proposed framework and methodolodical support of ICF. More attention is planned to be paid to the processes of identification of domain parts reasonable for automation and to systematic software reuse opportunities in the context of Model-Driven Development.

Fig. 1 .

 1 Fig. 1. General scheme of technology transfer process

Fig. 2 .

 2 Fig. 2. The overall structure of reuse-oriented framework

Fig. 3 .

 3 Fig.3. The two-life-cycle model of domain and application engineering[START_REF] Linden | Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering[END_REF]

Fig. 4 .

 4 Fig. 4. Integration in ICF

Acknowledgments. This work is partly financed by the European Union (European Regional Development Fund) within the Baltic Sea Region Programme 2007-2013 project BONITA (Baltic Organisation and Network of Innovation Transfer Associations). The present activity is partly funded by the ERDF project "Support of FP7 ICT STREP project "Simulation Highway"". This work has been supported by the European Social Fund within the project "Support for the implementation of doctoral studies at Riga Technical University".


Darius Dilijonas
email: darius.dilijonas@khf.vu.lt

Virgilijus Sakalauskas
email: virgilijus.sakalauskas@khf.vu.lt

Self-service Systems Performance Evaluation and Improvement Model

Keywords: Self-service, ATM, productivity, profitability, ANN

The paper analyses the topic of service system productivity and profitability. Main focus of the research is self-service area, namely, the increase of ATM network productivity. Paper presents performance evaluation of self-service systems and improvement model for its increasing profitability. This model combines internal and external quality criteria and provides detailed understanding of the main components of productivity evaluation and methods. Using the model it is possible to create evaluation and improvement tools for increasing productivity of self-service systems. Experimental result shows that using the developed productivity model, ANN method and optimization procedure, productivity of ATM cash management could be increased by approximately 33 percent.

Introduction

Globalization and market liberalization imply changes in basic economic understanding. Organizations begin to realize that the essential issue is not just profit maximization but profit maximization by increasing consumers' satisfaction with the provided services. At present, not just the delivery of services is important; more attention is given to the way of providing the services. Development of information technologies significantly impacts the render of services and the entire sector of services. Consumers now have more information and better understanding of any service, therefore, the competition between service providers is determined by quality, and quality determines profitability [START_REF] Seth | Service quality models: a review[END_REF]. Gartner [START_REF]Gartner: Emerging Technologies Will Help Drive Mainstream BI Adoption[END_REF] notices, that there have been major changes in the service sector. Traders are beginning to realize that technologies may have critical importance for the increase of profit and operational efficiency.

The paper analyses the topic of service system productivity and profitability. The work focuses on self-service area, namely, the increase of ATM network productivity. The profitability of electronic service systems depends on their productivity and quality of the services provided. It is possible to ensure the productivity of service systems by efficient planning and by improving delivery process. In order to avoid affecting delivery process in service systems, it is very important to make timely decisions. It is impossible to store services like goods; therefore, inadequate decisions are related to the direct loss of income and quality decrease.

The productivity of electronic services may be ensured by implementing advanced real-time decision management systems and by changing the realization of service system quality from traditional to predictive. The quality of such systems is ensured by predicting service system behavior. Multi-agent technologies are used for data collection from distributed service points [START_REF] Dilijonas | Retail banking optimization system based on multi-agents technology//16th[END_REF]. Intelligent agents evaluate the demand of service system resources according to the collected data, and plan the work to have sufficient resources for services and to maintain high quality and maximum system availability. Applying intelligent systems of resource planning and optimization, the work of service system must be managed in real time. Certainly, without service quality and productivity management models and systems, the mentioned measures are only the tools; therefore performance management models should be applied as well.

The goal of the research is to perform evaluation of self-service systems and to develop improvement model for increasing its profitability. Service system profitability increases when improves the quality of provided services and decrease supply costs. Due to insufficient level of their computerization, the developed method may be hardly applied for rendering traditional services. Therefore, more restricted area of service systems is analyzed in the paper -self-service facility systems -ATM networks.

The second section of the paper presents analysis of the literature concerning service systems productivity. The self-service systems performance evaluation model is described in the third section. The forecasting and optimization methods are described in the fourth section. According to presented evaluation model, fifth section provides detailed description of experimental results of ATM networks profitability simulation.

Service Systems Productivity

The concept of productivity in service area started to be analyzed only at the end of the XX century. Service sector is one of the fastest growing economy segments [START_REF] Sahay | Multi-factor productivity measurement model for service organization[END_REF]; still only few empirical surveys have been conducted in productivity management area. Gronroosa [START_REF] Gronroos | Service productivity Towards a conceptualization of the transformation of inputs into economic results in services[END_REF], Chase and Haynes [START_REF] Chase | Service operations management. A field guide[END_REF] structured the elements of service productivity theory. They analyzed the similarities and differences of production and service productivity, and formulated the main definitions of service productivity. Ojasalo [START_REF] Ojasalo | Conceptualizing productivity in services[END_REF] structured the model of service productivity. Sherman [START_REF] Sherman | Service Productivity Management, Improving Service Performance using Data Envelopment Analysis (DEA)[END_REF] defined service productivity components. Seth [START_REF] Seth | Service quality models: a review[END_REF] carried out survey on quality management models, developed in the period of 1984-2003. It is obvious that service delivery process changes from traditional to the one reasoned by information technologies. Application of information technologies in service quality management is becoming highly important. Service sector productivity depends on technologies and process automation measures [START_REF] Gummesson | Productivity, quality and relationship marketing in service operations[END_REF], at present this tendency is even more significant because the competition in service sector is increasing. Service delivery through self-service terminals or computer systems allows increasing the efficiency of service system and the quality of providing services. It is obvious that higher profitability is typical for efficiently operating systems [START_REF] Sherman | Service Productivity Management, Improving Service Performance using Data Envelopment Analysis (DEA)[END_REF].

Semeijn and others [START_REF] Semeijn | E-services and offline fulfillment: how e-loyalty is created[END_REF] showed that the work of servicing system is none the less important than the e-service system itself. Implementation of the best and most functional ATMs cannot ensure high level of self-service facilities without an appropriately functioning service system. Voss's [START_REF] Voss | Rethinking paradigms of service -service in a virtual environment[END_REF] survey shows that service quality expectations in retail banking only approximately fulfill the service received. Problems, which appear in service systems, may disturb delivery process [START_REF] Zhang | A consumer perspective of e-service quality[END_REF]; in most cases unavailable services greatly reduce the loyalty of a service [START_REF] Watcher | Longitudinal assessment of web retailers: issues form a consumer point of view[END_REF]. For this reason it is important to combine internal and external quality criteria. Only one or another group of criteria is usually analyzed in literature, and a common model of self-service network quality is not provided.

Productivity evaluation system of e-services is discussed by Gronroos [START_REF] Gronroos | Service productivity Towards a conceptualization of the transformation of inputs into economic results in services[END_REF]; Ojasalo, [START_REF] Ojasalo | Conceptualizing productivity in services[END_REF]; Rutkauskas et al. [START_REF] Rutkauskas | Concept of Productivity in Service Sector[END_REF]. Service productivity management is a very important topic, but very little empirical research has been carried out in this area [START_REF] Johnston | Service productivity: Towards understanding the relationship between operational and customer productivity / R. Johnston[END_REF]. Productivity consists of 4 components [START_REF] Sherman | Service Productivity Management, Improving Service Performance using Data Envelopment Analysis (DEA)[END_REF]: price, resource allocation, technological and scale efficiency. The main dilemma of productivity is balancing of revenue and costs [START_REF]Gronroos: Service management and marketing. A customer relationship management approach[END_REF]. Depending on demand, it is necessary to ensure efficient use of resources because services cannot be stored. Productivity is divided into internal and external. Internal productivity describes how efficiently resources are used. External productivity shows what service profitability is. Services productivity is the balance of external and internal efficiency [START_REF] Chase | Service operations management. A field guide[END_REF]. Another important element of productivity is demand management or capacity efficiency, because supplier cannot store services [START_REF] Gronroos | Service productivity Towards a conceptualization of the transformation of inputs into economic results in services[END_REF]. Capacity efficiency shows how efficiently system internal resources satisfy the demand. The process of services is an open system therefore application of traditional efficiency evaluation systems may determine false results. Productivity may be evaluated totally or partially. According to Gronroos [START_REF] Gronroos | Service productivity Towards a conceptualization of the transformation of inputs into economic results in services[END_REF], the only theoretically and practically significant way to calculate services productivity is financial measures.

Internal quality of a system is ensured by using advanced management tools, that allow optimizing operational costs and service delivery process, and by using internal quality management systems, which are based on sets of productivity criteria. Clearly detailed productivity criteria of ATM network internal quality management systems are analyzed in articles of Aldlaigan and Buttle [START_REF] Aldlaigan | SYSTRA-SQ: a new measure of banks service quality[END_REF], Bahia and Nantel [START_REF] Bahia | A reliable and valid measurement scale for the perceived service quality of banks[END_REF], Jabnoun and Al-Tamimi [START_REF] Jabnoun | Measuring perceived service quality at UAE commercial banks[END_REF], Joseph and Stone [START_REF] Joseph | An empirical evaluation of US bank customer perceptions of the impact of technology in service delivery in the banking sector[END_REF]. In order to ensure external quality, process development measures and external quality management systems are necessary. External quality management systems were analyzed by Lovelock [START_REF] Lovelock | Functional integration in service: understanding the links between marketing, operations, and human resources[END_REF], Johnston and Clark [START_REF] Johnston | Service Operations Management[END_REF], Edvardsson and others [START_REF] Edvardsson | Values based service brands: narratives from IKEA[END_REF], they settled value-based service quality management models, which analyze economic and social service delivery aspects.

Self-service Systems Performance Evaluation

The main quality evaluation criteria of self-service systems were analyzed by Aldlaigan and Buttle [START_REF] Aldlaigan | SYSTRA-SQ: a new measure of banks service quality[END_REF], Bahia and Nantel [START_REF] Bahia | A reliable and valid measurement scale for the perceived service quality of banks[END_REF], Jabnoun and Al-Tamimi [START_REF] Jabnoun | Measuring perceived service quality at UAE commercial banks[END_REF], Joseph and Stone [START_REF] Joseph | An empirical evaluation of US bank customer perceptions of the impact of technology in service delivery in the banking sector[END_REF]. Most authors distinguish 5 criteria, which make the basics of ATM service quality: sufficient size of ATM network, safe environment, userfriendly connection, convenient allocation, and ATM functionality. Evaluation of service delivery should be carried out according to the criteria of e-service benefit/value: environmental features, security, communication speed, reliability, customer support, responsiveness, information completeness, availability, delivery and personalization [START_REF] Rowley | An analysis of the e-service literature: towards a research agenda[END_REF].

The figure 1 shows the model of self-service system performance criteria; the model elaborates productivity components and sets out methodologies, which may be applied to ensure internal, external and capacity efficiency. It was found that internal productivity of self-service terminals may be increased by using cheaper maintenance resources if it does not have negative impact on quality, also by implementing more advanced technological decisions, and by optimal distribution of resources. Service resources may be optimized the way that their amount in self-service infrastructure would always satisfy the demand, therefore it is necessary to know what the demand will be, and forecast tools used for its determination. Knowing the demand, it is possible to foresee necessary amount of resources, and this is especially important in such service systems, where resources are of short validity or are realizable and can be used to earn income by another way.

Fig. 1. Self-service system performance criteria model

Productivity is comprised of several components that independently influence the overall efficiency of the organization. The components are 1) price efficiency, 2) allocative efficiency, 3) technical efficiency, and 4) scale efficiency [START_REF] Sherman | Service Productivity Management, Improving Service Performance using Data Envelopment Analysis (DEA)[END_REF]. Price efficiency requires purchasing the inputs that meet the quality standard at the lowest price. Allocative efficiency is the use of the optimal mix of inputs to produce the products or services. Technical inefficiency exists when it is possible to produce more outputs with the inputs used or where it is possible to produce the actual outputs with fewer inputs. Scale efficiency is the component that addresses the optimal activity volume level, producing more or less goods or services than the optimal level results in added costs solely due to volume or size [START_REF] Sherman | Service Productivity Management, Improving Service Performance using Data Envelopment Analysis (DEA)[END_REF].

Different management tools and methodologies can be used to evaluate and manage service productivity. In model, these tools are classified by three categories: K -Qualitative, S -Quantitative and without marking both K/S.

The model line connecting the methodology and the performance component shows which technique is applicable to evaluate performance of specific component. The external productivity consists of profitability and quality evaluation criteria's.

Self-service Systems Performance Assessment Model

Productivity may be evaluated by physical, financial and combined measures; they may totally or partially evaluate productivity [START_REF] Ojasalo | Conceptualizing productivity in services[END_REF]. All productivity evaluation criteria may be derived from them (Table 1), in accordance with the self-service systems performance criteria model. DEA analysis [START_REF] Sherman | Service Productivity Management, Improving Service Performance using Data Envelopment Analysis (DEA)[END_REF] is most suitable for evaluation of internal performance of selfservice systems.

Fig. 2. The model of self-service system performance assessment

Electronic services quality model is applied for the evaluation of external performance of self-service systems [START_REF] Santos | E-service quality: a model of virtual service quality dimensions[END_REF]. This model provides full set of criteria for the assessment of service content and functionality. IT-based model [START_REF] Zhu | IT-based services and service quality in consumer banking[END_REF], which assesses IT importance for the delivery of services, is applied for evaluation of social aspects: age, mood for using e-services.

The figure 2 presents self-service system performance model. Self-service system performance assessment model needs to be formulated in accordance with the criteria, formulated in the table 1. First the calculations are prepared and then the most appropriate evaluation criteria are selected. Following this, the productivity model is developed and simulations consisting real data are done. The obtained results are evaluated by comparing the results between ATM's. After analysis of the results, the reasons for low productivity are identified. Eventually tools have to be prepared to eliminate the causes of low productivity. The goals are set for performance improvement. After the changes and improvement are made, the comparison has to be done, in order to evaluate whether the realized changes increased productivity.

Profitability Simulation

This section describes experimental results of ATM network profitability analysis, using proposed performance evaluation methods and models.

Artificial Neural Network Model of Demand Forecasting

A flexible neural network model has been created, which changes its structure depending on situation and is used to forecast self-service facility demand. Considering the forecast results, the optimization procedure foresees optimal resource loads of ATM network.

In our past researches we have already presented experimental research of ANN model [START_REF] Simutis | Cash demand forecasting for ATM using neural networks and support vector regression algorithms // Continuous optimization and knowledge-based technologies : 20th EURO Mini conference[END_REF]. We came to the conclusion, that the best forecasting results are reached using direct spread multilayer neural network with one hidden layer, consisting of fifteen neurons in the hidden layer (transfer function -hyperbolic tangent) and one output (linear neuron), chosen for ATM cash prediction. Neural network has 6 inputs: average cash demand of the last 7 days, day of the week, month of the year, day of the month, days before holidays and time series record number. The output is ATM cash demand forecast for the following day or week if week discretion data is transferred.

Flexibility of neural network is controlled by limiting the weight of neural networks. For this reason, additional member D is introduced into the neural network prediction error expression, which punishes the network for high weight values (i.e. too high flexibility).

ATM Network Optimization of Resource Delivery

ATM network optimization topics include three areas: selection of optimal ATM network size [START_REF] Mcandrews | Shared ownership and pricing in a network switch[END_REF], cash demand specifics (size of cash on the market) [START_REF] Boeschoten | Cash management, payment patterns and the demand for money[END_REF][START_REF] Viren | Financial innovations and currency demand, some new evidence[END_REF][START_REF] Snellman | ATM Networks and Cash Usage, Fore presentation at the FMG/Cass Business School Workshop on "Financial Regulation and Payment Systems[END_REF][START_REF] Stix | How do debit cards affect cash demand? Working Paper 82[END_REF], and forecast of cash flow demand in ATM networks [START_REF] Simutis | Cash demand forecasting for ATM using neural networks and support vector regression algorithms // Continuous optimization and knowledge-based technologies : 20th EURO Mini conference[END_REF][START_REF] Sakalauskas | Intelligent systems for retail banking optimization-Optimization and Management of ATM Network System[END_REF]. Analysis of applied methods showed that most frequently analyzed economic models (dependencies) influence cash market structure by factors. Real decisions and tools, which could help to optimize ATM cash management, are not provided.

For profitability modeling we are using ATM optimization function to model such amounts of cash load, which minimize ATM operation expenses. Optimization is performed in consideration of interest rate, upload costs, forecast recommendations and cash management limitations: cash balance, cash insurance expenses, maximum amount of cash, minimal amount of cash, possible ATM unavailability period. Output of optimization function is the date of cash upload into ATM and optimal cash amount, which is necessary to upload in an ATM in order to minimize ATM operation expenses.

ATM cash management costs = Cash * Interest + Cash * Insurance + (RUC or EUC) + Penalty → minimize, where

Cash -ATM cash amount (limitations: possible minimum and maximum load); Interest -interest rate, %; Insurance -insurance rate, %; RUC -Regular upload costs; EUC -Extra upload costs; Penalty -penalty if ATM is not accessible more than 2% of all working time.

ATM Networks Profitability Simulation

Experimental research of 2 types has been carried out in the paper: low load and high load ATM network profitability simulation. High load ATM networks are replenished more than one time per day, via versa low load. For high load ATM network simulation we used India bank data of 5500 ATMs (duration up to 3 months). For low load ATM network simulation we used data of Lithuanian bank of 21 ATM (duration -6 months). In both cases we evaluated optimal (when ANN method is used) and typical (real bank process) models.

After modeling high load ATM network productivity, we found that average productivity of ANN model for a group of accurate ATMs is 17.73 % (assessing losses 11.16%). Optimal model, compared to a typical one is 18% more productive. This criterion characterizes capacity productivity component and shows how productively the existing resources may be used. It is attributable to financial productivity criteria, and only partially evaluates productivity. The amounts of cashback are decreased by 90%. This criterion shows the productivity of resource distribution.

ATM model average productivity for a group of average ATMs is 26.27% (assessing losses 12.18%), amounts of cash-back are decreased by 32.2% (assessing loss 11.16%), and the amounts of cash-back are reduced by 653%. Benefit without loss is the highest in the group of inaccurate ATMs, its increase is determined by obvious facts, i.e., bigger amounts of cash are uploaded in hardly forecasted ATMs, because standard deviation is much higher than in the case of accurate and average group models.

In After modeling low load ATM network productivity (detailed evaluation results are presented in Tables 2 and3), we found that in optimal case average cash-back amounted 13.15%; in typical case -37.23%. Using the created ATM network cash management model, the amounts of cashback were decreased by 24.08%, compared to a real scenario. Model efficiency shows that using the created ANN method and optimization procedure, the cash supply productivity of certain ATMs may be increased by 44.75% (ATM5011), 45.90% (ATM2001).

Figure 3 presents graphic generalization of modeling results of ATM No 5011; we notice that in case of optimal scenario, cash collecting is balanced in respect of cash demand. Using the created ANN method and optimization procedure, cash supply productivity of ATM5011 is increased by 44.75% (ATM5011), compared to the model, applied in a bank. Using the created ATM network cash management model for low load ATM network management, the cash-back amounts are reduced by approximately 24%, compared to a real scenario. Using the created ANN method and optimization procedure, ATM cash management performance may be approximately increased by 33 %.

Conclusions

The productivity of electronic services may be ensured by implementing advanced real-time decision management systems, i.e., changing the realization of service system quality from traditional to predictive. Application of information technologies in service quality management is becoming highly important.

The work of service system must be managed in real time, applying intelligent systems of resource planning and optimization. Certainly, without service quality, productivity management models and systems, the advance software is only a tool; therefore performance management models should be applied as well.

It was found that internal productivity of self-service terminals may be increased by using cheaper maintenance resources, by implementing more advanced technological decisions, and, by optimal distribution of resources. More productive distribution of resources may be performed using accurate service demand forecast measures.

Analysis of high and low load ATM network profitability showed that proposed self-service systems performance evaluation and improvement methods allow decreasing the amounts of cash-back by 24% and increasing cash management productivity up to 33%.

  = (work time / average time of one transactions) * number of terminals | maximum limitation under the overall load condition; FIZ MEF PP Total Load = number of transactions performed / total amount of resources; FIZ MEF PP Total "Freeze" Resources = returned or lost resources / all resources | rating for all terminals FIZ MEF PP Total Availability = no working time / total hours worked | rating for all terminals terminals; Service delivery efficiency = [revenue of service = (transaction price + sold product)] / all costs | | rating for all terminals; of transactions or sold product units / (outsourcing, depreciation, maintenance, support or services delivery costs) KOM KNAS DP

Fig. 3 .

 3 Fig. 3. Cash load model of ATM5011

Table 1 .

 1 Self-service systems productivity evaluation criteria's.

	Evaluation criteria	Features 1	Component 2	Type 3
	Maximum Capacity = work time / average
	duration of one transaction

  regard to accurate ATM group, a network of 5000 ATMs can save 4250 Euros per day, and if the free cash is lent, 2660 Euros may be earned. Total saving and profit benefit would reach 6900 Euros per day, what would allow making 2.52 million Euro profit per year. Average profit of all model groups is 2.35 million Euros per year. Cash management costs are approximately reduced by 25%.

Table 2 .

 2 ATM network management efficiency modeling results of the Lithuania Bank(Optimal Model)

	Optimal model (using ANN forecasting and optimization procedures)
	ATM number	ATM5011 ATM1004 ATM1045 ATM2001 ATM7012
	From	2009-5	2009-2	2009-3	2009-5	2009-5
	Till	2010-2	2009-11	2010-2	2010-2	2010-2
	Average load	73928	58752	35732	36574	39695
	Average Cash back	4225	5462	8277	3687	6938
	Cash Back %	5.71%	9.30%	23.17%	10.08%	17.48%
	Cash Load Quantity	50	46	36	35	31
	Cash Price (interest from	244	400	723	281	460
	cash back)
	Cash Load Price	1225	1125	875	850	750
	Total Cash Price (CB)	1469	1525	1598	1131	1210
	Frozen Cash (interest)	1469	2188	1709	1457	1264
	Total Cash Price (UZ)	3409	3313	2584	2307	2014
	Efficiency (CB)	47.11%	59.77%	-2.51%	68.88%	28.80%
	Efficiency (UZ)	44.75%	28.20%	28.36%	45.90%	15.18%

Table 3 .

 3 ATM network management efficiency modeling results of the Lithuania Bank(Typical Model)

		Typical model (typical bank scenario)
	ATM number	ATM5011	ATM1004	ATM1045 ATM2001 ATM7012
	From	2009-5	2009-2	2009-3	2009-5	2009-5
	Till	2010-2	2009-11	2010-3	2010-2	2010-2
	Average load	147616	88533	58685	46321	41401
	Average Cash back	27505	49540	14313	26190	12686
	Cash Back %	18.63%	55.96%	24.39%	56.54%	30.64%
	Cash Load Quantity	38	49	23	59	34
	Cash Price (interest	1827	2566	984	2158	850
	from cash back)
	Cash Load Price	950	1225	575	1475	850
	Total Cash Price (CB)	2777	3791	1559	3633	1700
	Frozen Cash (interest)	5220	3390	3031	2789	1525
	Total Cash Price (UZ)	6170	4615	3606	4264	2375

Features: FIZ -physical, FIN -financial, KOM -combined;

Component: KNAS -Price efficiency; IPNAS -Allocative efficiency; TNAS -Technical efficiency ; MEF -Scale efficiency; PEL -Profitability;

Type: PP -total productivity; DP -partially productivity;