Cost-based Deployment Planning for Components ...

Cost-based Deployment Planning for Components in Smart Item Environments J¨urgen Anke SAP Research CEC Dresden, Germany Dresden University of Technology, Germany Email: [email protected]

Abstract Middleware for smart items can facilitate the coordinated execution of distributed components for early data processing. These components can be deployed to different nodes in the middleware or even on the smart item itself. While such flexibility is desirable to fulfil various information requirements from backend applications, it poses the problem of finding good distributions for given components and component compositions. In this paper, we present an approach for deployment planning of components based on their expected resource consumption under a certain load. Using an example scenario we analyse the influencing factors on placement decisions. These are integrated into an evaluation schema. The concept is proven by an implementation, which is used to find suitable distributions for the example scenario with varying loads. We present the results and discuss the effect of different load settings.

1. Introduction Smart items are physical products that include product embedded information devices (PEIDs), e.g. embedded systems, or RFID tags. For application domains such as Product Lifecycle Management (PLM), enterprise applications can benefit from accessing data on smart items. This can replace error-prone manual data input with automatic data aquisition to support maintenance planning, recycling decisions, and improvements in the product design. As it is not reasonable to integrate mechanisms for accessing PEIDs into business applications, placing this functionality into a middleware is a useful approach. Such a middleware and the PEIDs form the smart item environment, which can be divided into three logical building blocks: PEIDs, Device Handler, and Request Handler. In a production system, these three logical parts will be a distributed system that spans different physical nodes. In the following, their functionality and physical distribution is briefly outlined. 1. PEID: The PEID contains data about the product and transmits it upon request. Data can be provided by

Klaus Kabitzsch Institute of Applied Computer Science Dresden University of Technology, Germany Email: [email protected]

reading from a local memory or by accessing sensors that are integrated in the product. If the PEID is an embedded system, it can contain local data processing, e.g. for continous recording of sensor data, or computation of statistics. In case the PEID is an RFID tag, the RFID interrogator can contain an embedded system to run programs. PEIDs can be mobile, e.g. if they are embedded into vehicles. Therefore they typically connect to Device Handler using wireless connections. 2. Device Handler: This is the PEID-specific part of the middleware and handles PEID detection and access. It notifies the Request Handler upon detected PEIDs, translates and executes the received requests in the PEID-specific protocol. Nodes that contain functionality of the Device Handler can be considered as access points for PEIDs and would be located nearby the Smart Item, e.g. in a garage, a depot, a warehouse etc. Depending on the application scenario there can be a number of Device Handler nodes, potentially supporting different PEID protocols. Device Handlers are connected to a Request Handler via high-capacity network connections. 3. Request Handler: The Request Handler is the PEID-independent part of the middleware. It manages incoming requests from backend applications. It stores them until a PEID becomes available on the network, and delivers it to the Device Handler node to which the PEID is connected. The Request Handler is the entry point for client applications, therefore it would be physically located nearby those systems. All of these nodes in the smart item environment can contain a standardised execution environment such as OSGi containers [1]. This turns the smart item environment into a distributed execution environment for software components, which allows for flexible distribution of components that format, analyse, or pre-process the data flows between backend applications and smart items. A detailed discussion on the reduction of data amounts in smart item environments by employing distributed components can be found in [2].

In this paper, we address the problem of component placement. We propose a method that supports the identification of suitable component distributions in a smart item environment. This paper is structured as follows: At first, we analyse the problem using an example and formulate a problem statement. Afterwards, we present our solution approach, followed by an implementation of the solution in Java, which is used to recommend distributions for the example scenario under different loads. These results are discussed to show how changes in the parameters lead to different distribution proposals. Afterwards, the related work is reviewed. The paper closes with conclusions and an outlook.

ferently, a set of PEID-specific components is used to convert the PEID-specific data representation into the required common format. Here, this is done by the components FormatOP, FormatRPM, FormatET. A Data Buffer component is used to buffer sensor data between the invocations of the component composition. Finally, the Aggregation component collects the partitial results and combines them into the final result, which is returned to the application.

Linear Regression

FormatOP

Data Buffer 1 Oil Pressure

Min/Max Aggregation

FormatRPM

Data Buffer 2

Classification

Engine Speed

2. Analysis Threshold

2.1. Example scenario The example scenario deals with maintenance planning for trucks. Data on the operational state of the vehicle is collected by the PEID and transmitted to a base station upon request from the maintenance application in the backend. The Device Handler is located in the depot and is connected to a Request Handler node, which accepts request from the application and notifies it when the result is available. The PEID is an embedded system in the vehicle, e.g. an on-board computer. It contains several data sources, such as counters and attached sensors (Figure 1). Data Sink

R equest H andler (D ata C entre) LAN /W AN D evice H andler (D epot) W ireless PEID (Vehicle) M ileage E ngine R PM tem p.

O il press.

Figure 1. Infrastructure in the example To get a comprehensive view of the vehicle’s operational status, the application requires the following information: (a) Current Mileage; (b) Engine speed, as distribution of time into categories slow, medium, fast; (c) Whether engine temperature remained within a given limit; (d) Trend and min/max of oil pressure. Within the middleware, a repository provides components which can be flexibly arranged in compositions to address new requirements. For the example scenario, the composition shown in Figure 2 is employed. It contains generic components for data analysis: Linear Regression, Threshold, Min/Max and Classification. Their class limits, thresholds etc. can be set with configuration parameters that become part of the composition description. Generic components require input data to be provided in a common format. As every PEID might supply its data dif-

Mileage

FormatET

Data Buffer 3 Engine Temp

Figure 2. Example component composition To deploy these components to the infrastructure mentioned before, a suitable distribution has to be found. A distribution is a set of component placements, in which every component is assigned to a node in the infrastructure. The complexity of identifying good distributions is caused by the number of possible mappings (combinations) of components to nodes, and the number of factors influencing the quality of a distribution. With an infrastructure of N nodes, and a composition of P components we get N P distributions to consider. In our example with N = 3 and P = 11, there are 311 = 177147 possible combinations. However, many of these combinations are are invalid due to violation of constraints. The remaining set of valid distributions has to be evaluated in terms of quality to identify the most suitable ones. For both aspects, the selection and evaluation of valid distributions, the following sets of factors have to be considered: 1. Resource constraints: The nodes on the network have different hardware capacities. These resource constraints rule out certain distributions, for instance, if the memory on a node is insufficient to hold all components that are assigned to it, or the bitrate capacity of a network connection is too low to handle the data amount to be transmitted. 2. Resource demands: The components involved in the component composition place resource demands on the infrastructure. These demands vary between the components, and can be dependent on other factors. For example, the bitrate requirements for a particular component composition depends on both the load and the input/output ratio of each component. 3. Performance measures: The performance of every distribution should be considered, e.g. in terms of response time and throughput. Similar to resource demands, there can be a demand for performance, which denotes the maximum response time allowed.

The number of influencing factors (F ) for a given case can be determined as follows: F = N Rn + Ln + P Dc + Lc + S + 1. Here, N is the number of nodes, Rn the number of resource types per node, Ln the number of network links (with only one resource), P the number of components, Dc the number of demand types per component, Lc denotes the number of component dependencies that carry bitrate demands, and S the number of data sources. The trailing 1 is the influencing factor ”invocations per hour” from the load model. In our example with N = 3 and P = 11, there are two resource restrictions per node, one resource restriction per network connection, for each component there are at least two resource demands, plus the demands for each connection between them. In total, there are 51 factors to consider. In summary, the component deployment planning decision is complex due to: (a) large number of possible combinations of components and nodes; (b) resoure restrictions that are very different among the nodes and network connections, (c) resource demands that vary by component and are partly load-dependent; (d) difficult performance estimation due to its dependency on the distribution, the load model, and the characteristics of both components and infrastructure. 2.2. Requirements When components or component compositions are deployed onto network nodes, there are traditionally two goals: either deployment is optimised for performance, or to fulfil restrictions caused by resource dependencies. The former deals with ensuring a certain response time or throughput. The latter refers to the existence of a technical environment, such as operating systems, execution environments, requirements for memory etc. In smart item environments, the situation is different. As a standard execution environment such as OSGi can be installed on all nodes including the smart item, components compliant to that standard can be run on every node. However, resources are scarce especially near the edges of the network. While it is necessary to save resources, this goal has to be balanced with performance requirements to provision requested data in reasonable time. A deployment planning method for components in smart item environments has the following requirements: 1. Consider resource restrictions for every node and network connection 2. Consider different loads 3. Evaluate resource demands, e.g. memory, bitrate 4. Evaluate performance, e.g. response time 5. Integrate performance and resource consumption into a single measure to allow for comparison and ranking of distributions

2.3. Problem statement Due to the large number of possible component placements, and factors that influence the quality of a distribution, planning of component deployment is a complex task. We argue that decisions on component placement have to be supported by a structured method. Not only does this reduce the complexity of the task, it also reduces the time that is needed for deployment planning. The solution has to evaluate component distributions with special regard to smart item environments, particularly the very heterogenous nodes and network connections. Furthermore, it has to consider different load parameters.

3. Solution approach The proposed method for component planning is designed as a decision support tool, i.e. it is intended for interactive use. The user, e.g. an administrator, can select the models for infrastructure and component composition, as well as a load model and a maximum running time. The method will then provide a number of recommendations for good distributions, from which the user can select one to start the actual deployment process. Alternatively, the method can be re-run with different parameter settings. User inputs: 3. Recommend (rank by score)

User-defined assignments

1. Modelling Infrastructure model Composition model

Load model

2. Evaluate (calculate score)

Cost of Resources

Figure 3. Solution overview Our solution consists of the three elements: modelling, evaluation, and recommendation (Figure 3). Modelling describes, how the infrastructure and the composition is being represented. Evaluation calculates the quality measure for a given distribution. In the recommendation part, possible distributions are generated, and the ones with best results are maintained in a list. In the following, the three elements are explained in more detail. 3.1. Modelling Modelling is used to describe the infrastructure as well as the component composition. Additionally, there is a load model to express the expected load. Infrastructure: The infrastructure is represented by an undirected graph (Figure 4). All nodes in the graph are annotated by a set of properties (Table 1). It is important to note that resources specified in the model are capacities, which are actually available for components, not the generally hardware equipment of a node. Although data sources and sinks are part of the infrastructure, they are not represented as nodes in the infrastructure graph. As they cannot be moved to other infrastructure nodes, they are modeled using static assignments.

Static assignments contain nodes of the component graph, which are assigned to a node of the infrastructure and not considered in the generation of distribution variants. This holds true for data sources and the data sink but can also be used for user-defined assignment of components, i.e. the user can manually assign components to nodes. Static assignments are represented are a set As of tuples Aij = (Ci , Nj ), where Ci is an element out of the set of components, and Nj is an element out of the set of infrastructure nodes.

Node Memory: xx CPU: xx

Connection

Node 1

Bitrate: xx Node 2

Node 3

Table 2. Properties of component graph Property

Applies Description to ID Node String identifier NODE TYPE Node Either Component, Data Source, or Data Sink Node Amount of memory this REQ MEM component requires (in KB) REQ CPU Node CPU power required for an invocation of this component GAIN Node Ratio of data input to data output for an invocation COMP LOAD Node Sum of ingoing data rates (in KB/s), for components only REQ BITRATE Edge Bitrate demand for this edge (in KB/s)

Node 4 Data Src 1

Data Src 2

Figure 4. Infrastructure graph Table 1. Properties of infrastructure graph Property

Applies Description to ID Node String identifier Node Available memory (in KB) AVAIL MEM MEM COST Node Cost for a unit of memory AVAIL CPU Node Available CPU power Node Sum of incoming data (in NODE LOAD KB/s) AVAIL BITRATE Edge Available bitrate of this network link (in KB/s) BITRATE COST Edge Cost for a consumed unit of bitrate on this edge Component composition: The component composition is represented as a directed acyclic graph (Figure 5), whereby the edges point in the direction of invocation. In other words, they show on which components a certain component depend on, e.g. as data input or for providing a particular functionality. Data sources and sinks are also added to the component graph, if components depend on them. Like the component composition graph, its nodes are annotated with properties (Table 2). The properties REQ BITRATE and COMP LOAD are assigned when the bitrate demands are calculated, which is performed in the Evaluation step, and uses the GAIN property. c1

c2

c3 Component



Data Src 1

Data Src 2

Memory: xx CPU: xx Gain: xx

Figure 5. Component graph

Load model: The load model we use here consists of number of invocations per hour, and the message sizes for every data source in the infrastructure. As the acquisition of monitoring data from products is usually performed in scheduled intervals, this rather simple load model is sufficient for our purposes. If necessary, it can also be extended to statistically distributed invocations. 3.2. Evaluation In the evaluation, a score for a given distribution is calculated. Distributions are represented like static assignments as (component, node) tuples. Before the actual evaluation can take place, dynamic resource demands have to be determined. Afterwards, the resource demands are assigned to the infrastructure and compared to the resource constraints. Finally, the consumed resources are evaluated to calculate the distribution’s score. Measure for distribution quality: To evaluate a distribution, a quality measure has to be defined. This quality measure allows comparing different distribution variants. As stated in the analysis section of this paper, resource consumption should be particularly considered. However, the resource consumption of a component composition depends only on the load model and does not change with different component placements. In reality, the quality of a distribution does depend on the actual placement of components. Therefore, the assessment of resource consumption alone is not sufficient. It seems to be obvious that resources should be saved on infrastructure elements, where they are particularly scarce. To incorporate this idea in the quality measure, we assign costs to weight the utilisation of different resources at individual nodes and edges of the infrastructure. Therewith we can express, for instance that a megabyte of memory is much more expensive on an embedded system compared to a middleware node. The same applies to network links, as the same amout of data transmitted over a GPRS connection between a PEID and a Device Handler will incur higher costs than on a LAN connection

between Device Handler and Request Handler. Costs can be assigned to every resource by the user and represent the ”exchange rates” between different resources. Thus, the user can state at which rate he is willing to invest more CPU power for data processing to decrease the bitrate demand as pre-processed data is smaller than raw data. According to requirement 5, resource consumption costs shall be integrated with performance measures. Performance mainly relates to response time, i.e. how long it takes to complete an invocation of the component composition. If we consider time as a resource, then it can be integrated with the cost of resource consumption. Response time also gets a cost assigned to it to specify the weight of this factor in relation to resource consumption. The ”overall cost of utilised resources” (OCUR) is calculated from Equation 1. OCU R =

Rk N

i=1 k=1

ni (k)Ci (k)+




nij Cij +tR CR (1)

Algorithm 1 calcBitrateDemands(startComp) Require: startComp
= 0 1: timeF actor ← invocationsP erHour ÷ 3600 2: while startComp has more edges do 3: e ← nextEdge 4: inputComp ← e.opposite(startComp) 5: if NODE TYPE of inputComp is component then 6: load = calcBitrateDemands(inputComp) 7: else if NODE TYPE of inputComp is datasource then 8: load ← inputComp.messageSize 9: e.REQ BITRATE ← load × timeF actor 10: end if 11: sumLoad ← sumLoad + load 12: end while 13: startComp.COMP LOAD ← sumLoad 14: return sumLoad × startComp.GAIN



In this equation, N is the number of nodes, Rk the number of resource types on every node, ni (k) is the resource consumption for resource k on node i, Ci (k) denotes the cost of resource k on node i, nij the resource consumption on edge between nodes i and j, Cij is the related resource cost. tR represents the response time, and CR the cost (weight) of the response time. Determine resource demands: Resource demands can be distinguished into load-independent and loaddependent demands. The only independent demand in our case is memory, as every component requires the specified amount of memory on the node. A load-dependent resource demand is the bitrate demand, which denotes the amount of data per time to be transferred between components. To calculate the bitrate demands, a recursive algorithm traverses the component graph starting from the data sink to the data sources. By multiplying the incoming data load with the input/output ratio (GAIN) it determines the loads on every edge based on the load model and assigns it to that edge (Algorithm 1). Detect constraint violations: Once all resource demands are known, they are assigned to the infrastructure graph. To achieve this, the evaluation algorithm (Algorithm 2) traverses through all elements (nodes and edges) of the component graph, finds the assigned element in the infrastructure graph, compares the sum of already assigned demand and new demand for all resources to their respective maximum capacity. If this combined demand is (still) less than the capacity, the new demand is added to that element. If a constraint is violated, it renders the whole distribution impossible and further analysis of this distribution is waste of computation time. Therefore the loop for demand assignments is quit and the result −1 is returned in this case. If all resource demand are assigned without violation of constraints, the distribution is valid. In this case, the quality measure OCUR is calculated (Equation 1) and returned as result.

3.3. Recommendation To find recommendable distributions, a number of distributions are generated and evaluated. The goal is to find valid distribtutions whose OCUR is as low as possible, because this denotes low costs of utilised resources and thus a good distribution. Algorithm 3 shows how this is achieved. First, we limit the maximum running time of the algorithm to maxT ime. Then the bitrate requirements are calculated using algorithm 1. A distribution candidate is generated and evaluated. If the determined OCUR is lower than the previous best score, it is stored in the variable bestDistr. The generation and evaluation of distributions is repeated until either the running time exceeds maxT ime or there are no more distribution candidates. Note that the algorithm shown does not make any assumptions on how the distribution candidates are generated. Any strategy from random assignments to preevaluations and sophisticated heuristics can be applied.

4. Experiments We have implemented a first version of the proposed method using Java and the JUNG library [3]. It can be used to find recommendations for distributions and considers bitrate and memory as resource types. First, we use the example scenario described in the ”Analysis” section and different parameters settings to show how they influence the result. Additionally, the achievable quality under restricted runtime is examined using both random generation of variants as well as exhaustive enumeration. 4.1. Distributions for the example scenario To identify a suitable distribution for the example scenario, we have assigned the required parameters in the model. Table 3 gives an overview of capacities and costs in the infrastructure, Table 4 contains the demands of all components.

Algorithm 2 evaluate(distr) Require: all resource demands are specified or calculated 1: error ← f alse 2: for all resource types rt do 3: for all component graph elements ce do 4: newDmd ← ce.getDemand(rt) 5: get infrastruct. element ie assigned to ce in distr 6: max ← ie.maximumCapacity 7: curDmd ← ie.currentDemand 8: if (curDmd + newDmd) > max then 9: error ← true 10: exit for-loop 11: else 12: ie.currentDemand ← (curDmd + newDmd) 13: end if 14: end for 15: end for 16: if error then 17: return -1 18: else 19: score ← calcScore() 20: return score 21: end if Algorithm 3 identifyGoodDistributions() Require: maxT ime > 0 1: startT ime ⇐ currentT ime 2: calcBitrateDemands(datasink) 3: while moreDistrAvailable and (currentT ime − startT ime) ≤ maxT ime do 4: curDistr ← getNextDistribution() 5: score ← evaluate(curDistr) 6: if score < maxScore and score > −1 then 7: maxScore ← score 8: bestDistr ← curDistr 9: end if 10: output(bestDistr) 11: end while

Suppose that under normal circumstances, the operational status would requested twice per hour. If we determine the best distribution by using exhaustive enumeration and setting maxT ime to 10 minutes. For invocationsperhour = 2, we get the result depicted in Figure 6. The OCUR of the identified distribution is 3151, and there was not a single invalid distribution. All components were assigned to the Request Handler node. The load in this case is so low that components would be placed on the node with the cheapest memory, which is also the one that contains the data sink. Let us assume that the truck driver had reported some technical problems recently, so it is decided to let the application check the vehicle’s operational status more often. It is now requested every minute. The sampling frequency of all sensors is increased accordingly to get more detailed results, and allow for early identification of prob-

Table 3. Infrastructure cost and capacities Node

Available Memory 2048 KB 20480 KB 51200 KB Available Bitrate 8 KB/s 8192 KB/s

PEID Device Handler Request Handler Link PEID ↔ Device Hdl Device Hdl ↔ Request Hdl

Memory Cost 15 3 2 Bitrate Cost 60 15

Table 4. Resource demands of components Component Aggregate Linear Regression Min/Max Classification Threshold FormatOP FormatRPM FormatET Data Buffer 1-3

Memory demand 200 120 30 300 150 200 220 200 50

Gain 1.1 0.05 0.05 0.2 0.05 1.4 1.5 1.4 1.0

lems to prevent damage. If the deployment planner is run with invocationsperhour = 60, it recommends the distribution shown in Figure 7. In this case, the distribution’s OCUR is 8750, and 174676 distributions were invalid (approximately 98.6%). Due to the higher load, some components were assigned to the PEID. Thus, data is processed early and reduces the amount of data that has to be transmitted over the network connection between PEID and Device Handler node. 4.2. Achievable quality with restricted runtime When only limited time is available, or the number of combinations is large, a complete evaluation of all possible distributions might not be feasible. In our method, Request Handler Aggregation Threshold

Min/Max

Classification

Linear Regression

FormatET

FormatRPM

FormatOP

Data Buffer 3

Data Buffer 2

Data Buffer 1 Device Handler PEID

Engine Mileage temp

RPM

Oil pressure

Figure 6. Result for 2 invocations per hour

Request Handler Threshold

Aggregation

Classification

FormatET

Min/Max

Data Buffer 3

FormatRPM

Data Buffer 2

Device Handler Linear Regression

FormatOP

PEID

Data Buffer 1

Engine Mileage temp

Oil RPM pressure

Figure 7. Result for 60 invocations per hour the execution time can be limited. The created result is the best distribution that could be found within the given amount of time. We have tested, which results are achievable when only a fraction of all possible distributions are evaluated. To this end, the example scenario with 177147 different distribution variants was evaluated with time restriction using both ”Random” and ”Exhaustive Enumeration” strategies. The result is shown in Figure 8. It can be seen from the chart that at already 10% coverage, the best found result was 98% of the optimal result. As expected, the ”Random” strategy converges sooner to the optimimum but its slope is not strictly increasing (to reduce outliers we have used the average of three runs for every point). The ”Exhaustive Enumeration” does always produce equal or better results with increasing coverage. ENUMERATION

RANDOM

100,5%

Score (OCUR)

100,0% 99,5% 99,0% 98,5% 98,0% 97,5% 97,0% 10%

20%

30%

40%

50%

60%

70%

80%

Distributions covered

Figure 8. Result at given coverage

5. Limitations and future work Currently, our implementation does not support evaluation of CPU loads and calculation of response times. In an existing approach [4], CPU requirements are expressed as a single number which is compared to the capacity. A

more sophisticated method uses a linear function to express the CPU usage depending on the load [5]. This might work well if all nodes have similar CPU power, like in grids. In smart item environments, the CPU of a middleware node might be 20 times more powerful than a CPU of a PEID, which makes it more difficult to express the CPU demand of a component. Thus, we plan to express the CPU demand of a component for processing a given data amount as percentage of CPU capacity on a reference system. The CPU capacity of every infrastructure node is then expressed as ratio to the CPU power of the reference system. With this ratio, and the component’s reference CPU demand we can determine the actual CPU demand for a given data amount to process. The response time for an invocation is the sum of partial times for processing, transmission, and queuing. An extensive body of knowledge has been established in the field of performance analysis, which provides methods for determining response times. In the future, we plan to use Network Calculus [6] to calculate delays.

6. Related work Component deployment planning has been done mainly in the area of grid computing and clusters. Kichkay et al present an algorithm for resource-aware deployment planning based on AI methods [7]. It requires a detailed specification of resource requirements for each component, and targets at deploying components to a wide-area network as typically found in grid infrastructures. The method computes a resource-optimal deployment plan, which fulfils a specific goal (such as component c1 should run on node n1) without breaking given resource constraints. Furthermore, additional components for encryption, caching etc. are added to the deployment plan if other components require characteristics that the infrastructure does not provide. A weakness of the approach is that it works on artificial intelligence methods, which are difficult to comprehend for a non-expert. Furthermore, it does optimise for a specific deployment goal instead of finding a generally good solution. An architecture for automatic deployment of components for scientific applications to grid environments is proposed by Lacour et al [8]. The assignment of components to grid nodes is done based on component dependencies on computing resources, libraries, operating systems etc. In contrast to our method, it does depend on a specific component technology, namely CORBA, which makes it unusable for our purpose. Steward et al present automatic deployment for components of a J2EE application running on a cluster of computers [5]. It is based on offline mapping of input workloads to resource-consumption profiles for all relevant components, e.g. web server, database, and EJBs. The goal of this method is to find a deployment that maximizes the throughput of the distributed application. It is not able to optimise for resource consumption. Besides deployment planning, there are a number of ap-

proaches for evaluating non-functional characteristics of component-based applications. One direction of research is the support of component composition support by providing a performance assessment at design time, i.e. the assembly of components. This is done for web-service based business processes [9] by measuring performance of atomic services, which are executed partly in a real environment and partly in an emulated environment. Another approach presented in [10] uses performance models for individual components that are combined into an overall performance model behind the scenes during component composition. Whereas this approach deals with performance evaluation for component-based systems, they do not address the planning of component deployment. A second direction of research deals with prediction of resource consumption to ensure a certain Quality of Service (QoS) [11]. If a current system configuration is unable to fulfil given contraints it is adapted. Relocation of components is one kind of adaption that can be performed in order to provide the requested service quality. However, the goal of QoS mechanisms is to ensure non-functional characteristics execution at runtime for existing component deployments. They do not specifically support initial component deployment planning.

[2] J. Anke and M. Neugebauer, “Early data processing in smart item environments using mobile services,” in Proceedings of the 12th IFAC Symposium on Information Control Problems in Manufacturing (INCOM’06), St. Etienne, France, 17-19 May 2006.

7. Conclusion

[7] T. Kichkaylo and V. Karamcheti, “Optimal Resource-Aware Deployment Planning for Component-Based Distributed Applications,” in Proceedings of the 13th IEEE International Symposium on High Performance Distributed Computing (HPDC’04). Washington, DC, USA: IEEE Computer Society, 2004, pp. 150–159.

We have presented a deployment planning method for components that address specifically distributed components in smart item environments. These networks are characterised by a high degree of heterogeneity in terms of available hardware resources. Furthermore, there is a danger of overloading the system by large amounts of data which is transmitted from smart items to backend systems. Our deployment planning method uses cost-based resource consumption assessment to find a good distribution of components. This approach allows for expressing substitution rates of different resource types, including response time. Using an example, recommendations for distributions were generated and discussed. Additionally, we showed which recommendation quality can be achieved when only a part of all combinations are evaluated. We will conduct such analyses with other example scenarios to validate our findings.

8. Acknowledgement The authors would like to thank Gregor Hackenbroich for his valuable comments. This work is partially based on the PROMISE project, funded by the European Union IST 6th Framework Programme, No. 507100.

References [1] OSGi Alliance, Open Services Gateway Initiative, 2006. [Online]. Available: http://www.osgi.org

[3] The JUNG Development Team, JUNG: The Java Universal Network/Graph Framework, 2006. [Online]. Available: http://jung.sourceforge.net [4] T. Kichkaylo, A. Ivan, and V. Karamcheti, “Constrained Component Deployment in Wide-Area Networks Using AI Planning Techniques,” in Proceedings of the 17th International Symposium on Parallel and Distributed Processing (IPDPS’03). Washington, DC, USA: IEEE Computer Society, 2003, p. 3.1. [5] C. Stewart, K. Shen, S. Dwarkadas, M. L. Scott, and J. a. Yin, “Profile-driven Component Placement for Cluster-based Online Services,” IEEE Distributed Systems Online, vol. 5, no. 10, Oct 2004. [6] J.-Y. L. Boudec and P. Thiran, Network Calculus: A Theory of Deterministic Queuing Systems for the Internet, ser. Lecture Notes in Computer Science. Springer, 2001, vol. 2050.

[8] S. Lacour, C. Perez, and T. Priol, “A Software Architecture for Automatic Deployment of CORBA Components Using Grid Technologies,” in 1st Francophone Conference On Software Deployment and (Re)Configuration (DECOR 2004), Grenoble, France, 2004, pp. 187–192. [9] L. Olkhovich, E. Rachinsky, and A. Hennig, Using Partly-Emulated Execution Environment for Measuring QoS-related Parameters of Business Processes. Magdeburg: Otto-von-GuerickeUniversit¨at, 10. June 2005. [10] X. Wu and M. Woodside, “Performance modeling from software components,” in WOSP ’04: Proceedings of the 4th international workshop on Software and performance. New York, NY, USA: ACM Press, 2004, pp. 290–301. [11] D. H. Akehurst, B. Bordbar, J. Derrick, and A. G. Waters, “Design Support for Distributed Systems: DSE4DS,” in Procedings of the 7th Cabernet Radicals Workshop, J. F. M. H. A. Montressor, Ed., October 2002.