A Cost Model for Efficient Business Object Replication

Transcription

1 2009 International Conference on Advanced Information Networking and Applications Workshops A Cost Model for Efficient Business Object Replication Michael Ameling, Bernhard Wolf SAP Research CEC Dresden Dresden, Germany michael.ameling;b.wolf@sap.com José Enrique Armendáriz-Iñigo Univ. Pública de Navarra Pamplona, Spain enrique.armendariz@unavarra.es Alexander Schill Technische Univ. Dresden Dresden, Germany schill@rn.inf.tu-dresden.de Abstract Replication in distributed systems is a solution to improve availability and reliability. To replicate business objects cached by the middleware we aim at replica control at application level. To reach an efficient replication within a service-oriented environment we have to understand the structure of business objects to be able to reduce data transfer and processing time of messages. In this paper, we introduce a general cost model for business objects to predict the processing time of BOs in dependency of their structure. A BO model is proposed to create profiles of BOs. A system model is introduced to predict the processing time. We experimentally prove that we are able to specify system parameters and BO model parameters for our cost model. The proposed solution enables the determination of the processing time of BOs at a sender during the update process of BOs. Finally, we introduce a how to modify the update process for an efficient replication with our cost model. 1. Introduction Nowadays, requirements for business processes are changing fast and demand high flexibility. How can information technology support the existing processes with low costs? An ubiquitous solution is to encapsulate business data in business objects (BO). BOs e.g., an Employee or a Sales Order present real objects or processes. BOs generally provide their functionalities through services; such as the invocation of a sales order process or the creation of a new Employee. BOs are usually hold within specific applications such as a customer relationship (CRM) or supply chain management (SCM) system. Applications are hosted on application servers; they are replicated, as well as the services provided by BOs, to provide faster local access and higher availability. Special attention has to be paid to the consistency of BOs. Users access BOs by the way of transactions to issue read and write operations. Hence, a replication protocol has to coordinate the execution of transactions in the replicated setting so that its history is equivalent to a transaction generated by a single object. Most industrial solutions [1], [2], [3] and many research solutions [4], [5], [6] for replication through application servers use the primary copy approach [7] for achieving an efficient replication since it is best suited for applications dominated by read operations. Using the primary copy approach update transactions are exclusively executed on the primary (master) for a BO. The other replicas (secondaries) just allow read-only transactions. The processing time for the update propagation to BO replicas can take a significant amount of time. The update message has to be assembled and transferred to all secondaries. Each secondary has to process the message and update the BO. Moreover, the size of BOs can vary tremendously and, hence, their structures and compositions have a crucial impact on the update process. From all the above it is important to optimize the update process. The decision is whether to send the complete BO state or only the data that has been changed in the BO. For example, a small and simple BO could be sent completely. On the master side parsing and filtering changes are avoided and, thus, time is saved. On the secondaries, this BO just has to be overwritten. The transfer time is not essential since the BO is very small. Whereas, there exist also very large and complex BOs; transfer time is increased due to the send of the complete BO. The alternative approach implicates additional effort at both sides, i.e. identifying changes during parsing the BO at the master. Therefore, the trade-off between the additional processing time at the master and secondaries and the saved transfer time has to be determined. Currently, the costs of all process steps are not determinable due to the varying size of BOs. The structure of the BO plays a crucial role. A model has to be defined for the master, the data transfer and the secondary, respectively. In this paper we introduce a general model for assessing replication processes for BOs with a detailed investigation of the processing time at the sender. Therefore, a cost model has been developed. The rest of the paper is organized as follows: Section 2 shortly introduces the system environment and a scenario. In Section 3 the structure of BOs and a cost model for the processing of BOs at the master is defined. Section 4 includes the experimental evaluation of the cost model. Section 5 refers to related work. Finally, Section 6 gives a conclusion and outlook /09 $ IEEE DOI /WAINA

2 2. Replication Scenario in SOA A BO B is changed to B at its master. To update a replicated BO B the content has to be preprocessed at the sender and a message has to be assembled, the message has to be transfered and the BO has to be integrated or replaced at the receiver. In Fig. 1 the processing time at the sender T S, the transfer of the message T N and the processing at the receiver T R for an update process are depicted. have a link instead of a value. The relation between a node (parent node) and subnode (child node) is also defined as composition. All other relations between nodes are defined as associations. A level describes the distance between a node and the root node. In the following a level with a higher number is called a deeper level and level with a lower number a higher level. Figure 2: BO Structure Figure 1: Update Process BOs can be very complex and vary in their structure. There exists an efficiency trade-off between sending the changes of a BO (case I) or its full copy (case II). Case I requires additional parsing at the master to transfer these changes in smaller messages. Furthermore, the changes have to be integrated on each secondary. In case II the master sends the full BO resulting in larger messages but there is no processing at the secondaries since the object is just replaced. In order to find this trade-off, it is necessary to determine the time spent in T S, T N and T R (Fig. 1). In the following the cost model for T S is introduced. 3. Cost Model for BOs The cost model for the processing of BOs at the master depends on the BO model and the system model. The BO model comprises all parameters to describe the structure of a certain BO and allows to create profiles of BOs. The system model includes the parameters describing the system environment and allows to create profiles for several systems. Finally, the knowledge of BO profiles and a system profile of the master machine allows to predict the costs for processing a BO at the master Structure of BOs The BO structure is defined as a tree-structure of an XML document (see Fig. 3) consisting of nodes, attributes and values. All BOs have one mandatory root node. Each node can have none, one or multiple subnodes and none, one or multiple attributes. Each attribute has a size. Nodes that do not have a subnode are leaf nodes. Only leaf nodes can have one value. Since BOs can link to other BOs a leaf node can In Fig. 2 an abstract structure of BOs is depicted. A node, denoted as node n, has the index n. The root node has the index n = 0. In the example, the nodes node 1, node 2 are subnodes of the root node node 0. An attribute (k n,λ ) is indexed by the index of the node n and the position λ. The size of the attribute has the value w n,λ. The index l describes the level. The root node is placed at level l = 0. The values v n and links f n have the index of the node. A simplified file sample of a Sales Order BO without links is shown in Fig. 3. The Sales Order consists of meta data (e.g.: ID, Date) and one item. Several items are usually possible. The root node is SalesOrder and always coincides with the name of the BO. The item consist of the product of type monitor. Some additional data such as Price including (Net) and (Gross) value are included as well. In the example, Identity and Item are subnodes of SalesOrder and placed at the first level. The nodes ID and Date are leaf nodes with their respective values. An example for attribute is currency. <?xml version="1.0" encoding="utf-8"?> <SalesOrder> <Identity> <ID>00001</ID> <Date>2008/06/31></Date> </Identity> <Item> <ID>0053</ID> <Product> <Type>Monitor</Type> <Price> <Net currency="eur">200</net> <Gross currency="eur">238</gross> </Price> </Product> </Item> </SalesOrder> Figure 3: An XML Sales Order Sample File 305

3 3.2. BO Model Based on the BO structure a BO model is defined. It describes single BOs and not the schema or the semantic of a BO. A complete list of the parameters of the BO model can be found in Table 1. The first parameters of the BO model are the number of nodes N and the number of levels L. The overall number of all attributes of a BO is K. The parameter N l describes the number of nodes at a certain level l. Since there can exist multiple attributes for one node the parameter Λ describes the maximum number of attributes for all nodes. The parameter K λ holds the number of attributes at position λ at all nodes. The parameter K n includes the number of attributes per node n. The total size of all attributes of a BO is W. The total size of all values of a BO is V. Both parameters can be determined for a level l with W l and V l. The size of all attributes per node n is W n and the size of all values for a leaf node n is V n. The size of an attribute at node n at position λ is W n,λ. The simplified example (Fig. 3) has 11 nodes including the root node (N = 11), 2 attributes (K = 2) and 5 levels L = 5. NOTATION N L K N l K l Λ K λ K n W W l W n W n,λ V V l V n F F l Table 1: Parameters of BO Model DESCRIPTION 3.3. System Model Number of nodes Number of levels Number of attributes Number of nodes at level l Number of attributes at level l Maximum number of attributes per node Number of attributes at position λ Number of attributes of node n Total size of all attributes (in bytes) Total size of all attributes at level l Total size of all attributes of node n Total size of all values of node n at position λ Total size of all values of leaf nodes Total size of values of leaf nodes at level l Total size of the value of leaf node n Number of links Number of links at level l The system model describes the processing for BOs at the sender side. The processing time of BOs depends on the number of nodes, attributes, etc. Furthermore, the it depends on the distribution of nodes and attributes. Therefore, the cost model has to consider e.g., the distribution of nodes at a certain level as well. The processing time for a single node at level l at position ν is described with the system model parameter a l,ν. (l and ν are used as indexes for nodes instead of n.) The processing time for an attribute at a node with index n and position λ has a fixed value b n,λ and a value c n,λ that depends on the size W n,λ. The processing time for a value at node n that is a leaf node is d n. The processing time for a value depends on the size V n. The processing time for a link at node n is e n. In Table 2 the system model parameters are listed. NOTATION a l,ν b n,λ c n,λ d n e n 3.4. Cost Model Table 2: Parameters of System Model DESCRIPTION time to process a node at level l at position ν time to process an attribute at node n at position λ time to process a Byte of an attribute value at node n at position λ time to process a Byte of a leaf node value at node n time to process a link at node n According to the BO model the processing time for a BO depends on a time for an offset and the processing time for all nodes, attributes, values and links. With the consideration of the BO structure the processing time of a BO at a sender, the total time T S can be described as follows: T S = T offset + T nodes + T attributes + T values + T links (1) The time for the offset T offset is caused by the time to load and access the BO document and also includes the time to access the root node. The time for the offset is a constant value for all BOs with the same size. The sum of the processing time of all nodes at all levels L N l and positions is: T nodes = a l,ν. All child nodes can be l=0 ν=1 processed in one cycle and results in a constant processing time for nodes at the same level. On the other hand, the child nodes of each node need to be processed separately which results in additional effort. Therefore, the processing time for node at a higher level increases for each additional level (a l < a l+1 ). Finally, the processing time is the same for all nodes at the same level ( ν l : a l = a l,νl ). With the BO model parameter N l we can use the following equation: T nodes = L (N l a l ) (2) l=0 The processing time for one attribute depends on the constant part b n,λ and the size W n,λ. Therefore, the sum of the processing of all attributes of a BO at all nodes and all N K n positions is: T attributes = b n,λ + W n,λ c n,λ. Similar n=0 λ=1 306

4 to the processing of nodes at one level the processing times of attributes at a position λ equals for all nodes. The fixed value b n,λ is the same for all nodes ( n: b n,λ = b λ ) and increases for higher positions (b λ < b λ+1 ). The processing time for the variable value is the same at all nodes and positions. Therefore, the sum of the size of all values can be multiplied by a value c ( n, λ: c n,λ = c). Finally, in combination with the BO model parameters K n, K λ and W the following equation can be used: K n T attributes = (K λ b λ ) + W c (3) λ=1 The sum of the processing of all values is: T values = N (v n d n). The processing time for values is the same n=0 for all nodes ( n: d n = d). The size of all values is the BO model parameter V. Finally, the equation for the processing of all values can be simplified as follows: T values = V d (4) The sum of the processing of all links is: T links = N e n. n=0 Equal to values the processing time of a link is the same for all nodes ( n: e n = e). The equation for the processing of all links can be simplified as follows: T links = F e (5) Finally, the processing time for all elements of a BO (T nodes, T attributes, T values, T links ) can be used in the equation for the processing time of a BO on sender side T S. The following equation T S allows to determine the processing time of a BO with the knowledge of the BO model and system model. T S = T offset + L K n (N l a l )+ (K λ b λ )+W c+v d+f e l=0 4. Evaluation λ=1 We did an experimental analysis of created BOs to prove the correctness of the introduced cost model. To show the dependencies we created BOs and adjusted single parameters. A further goal is to determine the parameters of the system model. In the following section the experimental evaluation of the assumptions from the previous chapter (Table 3) is described. (6) Table 3: Assumptions for the Cost Model NOTATION a l,ν = a l b n,λ = b λ c n,λ = c d n = d e n = e DESCRIPTION 4.1. Experimental Validation The processing time for a node without any attributes is same for all nodes ν at level l The processing time for an attribute with fixed size at position λ is the same for all nodes n The processing time for the attribute content is the same for all nodes n at all levels l The processing time for node values is the same at all nodes n The processing time for solving a link is the same at all nodes n The system used for measurements has a CPU with 1.6GHz and 2GB RAM. The measurements were done with the JDOM [8] implementation for parsing. The documents of the origin BO have a fixed header which does not belong to the BO data. The body represents the BO with the BO name as root node. The experiments labeled in capital letters include changes of the structure and the content of BOs in the body part of the document. Each experiment has been repeated 100 times. The results represent the minimum values of the processing times measured in nanoseconds. The experiment A 1000 shows that the processing time is equal for each node at the same level. Firstly, a BO with a root node was created. We increased the number of nodes up to 1000 nodes (Fig. 5a) where all nodes are placed at the same level L 1. The generated documents present BOs with a very flat structure. The total processing time for each BO can be seen in Fig. 4 (graph A 1000). The increase of the number of nodes affects the processing time linearly. The intersection with the ordinate at 1.23s is caused by the header of the document and the BO loading. However, the result reflects the assumption that the processing time for each node at the level is the same. The experiment B 1000 shows that the processing time for a node increases when the node is placed at a higher level. Similar to the experiment A 1000 a BO with a root node was created. The number of nodes was increased where each additional node was placed as child node of the leaf node (Fig. 5 b). The created BO represent BOs with a very deep structure. Each additional node increased the number of levels by one. The graph B 1000 in Fig. 4 shows that the total processing time of the BO increases quadratically. The distance for the processing times for additional levels increases linear which can be seen in the following experiment. In experiment C a fixed amount of nodes was moved across all 1000 levels. The origin BO has 1000 nodes in a vertical order. Therefore, it has 1000 levels with one node per level. Then, 10 (C 10), 100 (C 100) or 1000 (C 1000) 307

5 Figure 4: Evaluation Results Figure 5: Experimental Procedure nodes were added as child nodes of the first node. The additional nodes were moved down to the last level (Fig. 5 c). The result is a linear function for all experiments C 10, C 100 and C If we divide the function by the number of nodes we have the slope that describes an equidistant increase of the processing time for the levels. Furthermore, we did experiments where we increased e.g., the number of attributes or moved attributes across levels. There, the assumptions listed in Table 3 were reflected equally to the previous experiments System and BO Profiling The values of the system model parameters (Table 2) for a specific system are stored in a system profile. It enables to exactly predict the processing time for BOs. The determination of a system profile is described as an example of the processing time for a node a l. In experiment B 1000 the processing time for BOs having only one node at each level is depicted in Fig. 5 (N l = 1 l). Since only nodes are used as BO elements we can use equation 3.4 with (N l = 1) and add the offset T offset : L T S = (a l ) + T offset. The measured value for the offset is: l=0 T offset = 1228 (all times are given in milliseconds). B 1000 can be well approximated by a quadratic function in l. Using the least squares method we obtain: B l l The derivative of B 1000 is the linear function a l = l Substitution into Equation 2 allows to compute the processing time for all nodes of a BO. We did further measurements with created BOs for the experiment B 1000 in D meas. The measured results D meas differ less than 2% from the prediction D pred. All other system model parameters can be determined similarly. The determination of the BO model parameters can be done by analyzing BOs initially. The BO model parameters can be determined also for linked BOs or even parts of BOs. The knowledge can be saved in static BO profiles. The profiles can be even used for different BOs since they are used usually within the same processes. The profiles can also be used for similar BOs or they can be clustered for BO types. 5. Related Work In this paper we introduced a cost model for the update process using the primary copy approach. We took advantage of previous research done by the database community on replication as there are a lot of similarities with our goal. However, one important issue for choice of a replication class is the read and write intensity of the replicas. Since we are dealing with business applications we have BOs with a high read intensity. In some cases the write intensity increases when new BOs are created; specially, the primary copy database replication approach [9], [10] which performs best for read-intensive applications [7]. There exist different approaches to reach consistency with a primary copy architecture. We followed the lazy (passive) approach due to the read intensity of business applications. In [10] a solution is presented that assumes very strong currency control. On the other side in [11] a relaxed currency serializability is introduced which allows update transactions to read out-of-date copies with the use of freshness-constraints for read operations. The cost model was proved experimentally using JDOM [8] for parsing. Other parsers which can be used in an additional evaluation are e.g., dom4j [12], XML Pull Parser (XPP) [13] or Xerces Java [14]. Standardized measurements can be achieved with e.g., TPC benchmarks [15]. Other approaches implementing a replication at the middle-tier are [16] (Middle-R), [17] (Ganymed) and [18], [19], [20] (CORBA). However, they do not provide a cost model 308

6 for the transfer of BOs and focus on strategies such as snapshot isolation [10]. An overview of middle-ware based data replication can be found in [21]. An approach improving the reliability and performance of Web Services is introduced in [22]. The throughput and the response time benchmark are sufficient to determine the transfer time of replication messages T N. However, it is not focused to do a modification on the network layer as it is aimed with XML compression. Theses solutions also do not involve the structure of BOs. 6. Conclusions A cost model for BOs which can be used to determine the processing time at sender during the update process was introduced. A BO model and system model were presented followed by an experimental validation of the cost model. The BO model enables to create profiles of BOs and to determine their processing time. The solution works for all types of BOs and allows to predict the processing time at different system environments. A system profile determination can be done with very low effort. Finally, another approach is to group profiles of BO types. Once the profiles exist the processing time for BOs can be estimated with a very high accuracy. The proposed procedure can be implemented in productive systems. The system can react more easily on e.g., load changes and new customer needs. However, the used algorithm has to ensure, that analysis and replication strategies do not increase the latency for user requests. Therefore, the procedure has to be able to serve a variety of business cases from very small applications up to very large applications with many users. The profiling of BOs can be done initially. The provided Web Service can be used to access BOs. The payload response of a Web Service request equals the payload of a replication request. A following publication will in include a comparison of different parser implementations. Further work is the determination of the message transfer time T N and the processing time at the receiver T R. References [1] JBoss, JBoss Clustering, The JBoss Group, [2] Weblogic, BEA WebLogic Server, release 7.0: Programming WebLogic Enterprise JavaBeans, BEA Systems Inc., [3] H. Wang and M. Bransford, Server Clusters For High Availability in WebSphere Application Server Network Deployment Edition 5.0, release 5.0 ed., Software Group, IBM Corporation, April [4] P. Felber and P. Narasimhan, Reconciling replication and transactions for the end-to-end reliability of CORBA applications, in DOA, [5] R. Barga, D. Lomet, and G. Weikum, Recovery guarantees for general multi-tier applications, in ICDE, [6] H. Wu and B. Kemme, Fault-tolerance for stateful application servers in the presence of advanced transactions patterns, in IEEE SRDS, [7] J. Gray, P. Helland, P. O Neil, and D. Shasha, The dangers of replication and a solution, in SIGMOD, 1996, pp [8] JDOM, JDOM project, [9] C. Plattner, G. Alonso, and M. T. Özsu, Extending dbmss with satellite databases, VLDB J., vol. 17, no. 4, pp , [10] K. Daudjee and K. Salem, Lazy database replication with snapshot isolation, in VLDB 06. VLDB Endowment, 2006, pp [11] P. A. Bernstein, A. Fekete, H. Guo, R. Ramakrishnan, and P. Tamma, Relaxed-currency serializability for middle-tier caching and replication, in SIGMOD 06. ACM, 2006, pp [12] dom4j, [13] XML Pull Parser, XPP, [14] Apache XML, Xerces Java Parser, [15] T. Description, Transaction processing performance council web page, [16] M. Patiño-Martinez, R. Jiménez-Peris, B. Kemme, and G. Alonso, Middle-R: Consistent database replication at the middleware level, ACM Trans. Comput. Syst., vol. 23, pp , [17] C. Plattner and G. Alonso, Ganymed: Scalable replication for transactional web applications, Middleware, pp , [Online]. Available: citeseer.ist.psu.edu/plattner04ganymed.html [18] O. Othman, C. O Ryan, and D. C. Schmidt, Strategies for CORBA middleware-based load balancing, in IEEE Distributed Systems Online, [19] M.-O. Killijian and J. C. Fabre, Implementing a reflective fault-tolerant CORBA system, in SRDS, [20] P. Felber, R. Guerraoui, and A. Schiper, Replication of CORBA objects, in Advances in Distributed Systems, S. Shrivastava and S. Krakowiak, Eds. LNCS 1752, Springer, [21] E. Cecchet, G. Candea, and A. Ailamaki, Middleware-based database replication: the gaps between theory and practice, in SIGMOD 08. ACM, 2008, pp [22] J. Salas, F. Perez-Sorrosal, M. Patiño-Martínez, and R. Jiménez-Peris, Ws-replication: a framework for highly available web services, in WWW,