Dynamically Scalable Architectures for E-Commerce

Transcription

1 MKWI 2010 E-Commerce und E-Business 1289 Dynamically Scalable Arcitectures for E-Commerce A Strategy for Partial Integration of Cloud Resources in an E-Commerce System Georg Lackermair 1,2, Susanne Straringer 1, Peter Mandl 2 1Cair for Business Informatics, Tecnical University Dresden 2Cair for Business Informatics, University of Applied Sciences Munic 1 Motivation E-commerce became an important economic factor during te last years. Approximately 38.5 million customers in Germany ave already bougt goods or services online. Furtermore te total revenue in Germany is expected to rise from 46 billion Euro in 2006 to 145 billion in Increasing mobile web usage and te trading firms' expanding international activities boost tis development even furter (Stal et al. 2009). Tis growing acceptance of e-commerce will result in an increasing number of bot transactions and customers. Considering te extensive and increasing usage of searc agents, web-crawlers and interactive elements in addition, workloads in e- commerce will rise significantly. Moreover, te advancing integration wit oter systems, like oter sops requesting catalogue data, causes additional requests to andle. At te same time, intense competition among retailers tends to result in more demanding requirements wit respect to functionality, usability, availability and performance. Rising workloads and more demanding requirements are nowadays andled wit statically scaled systems, were te capacity is determined by te expected maximum workload. Tis results in low resource utilization in data centers conflicting wit rising energy costs and CO 2 emissions. Fluctuation in workloads impairs te situation even furter. After Microsoft released Windows 7, various news cannels and blogs reported tat many online sops ad serious performance problems and some servers broke down completely (Computerbase, 2009; Cronicle, 2009). Tis igligts te problem tat workload forecasts are difficult and tat surges of visitors can exceed te expected maximum workload significantly. An examination of a B2B sop system sowed

2 1290 Georg Lackermair, Susanne Straringer, Peter Mandl tat even in tis domain te workload fluctuation is an issue. Te Windows 7 example points out tat forecasting workloads and ad oc extension of computing power pose problems still to be solved. A solution to tese problems could be provided by a strategy for partial integration of cloud computing resources in e-commerce systems. Tere are many different definitions of cloud computing (Armbrust et al. 2009; Hayes, 2008). In our work we focus on te usage of virtualized computing capabilities on te internet, wic is also called utility computing or Infrastructure as a Service (IaaS). Turban et al. (2008, p ) define utility computing as computing power and storage capacity tat can be used and reallocated for any application and billed on a pay-per-use basis. A strategy for a partial usage of suc virtualized resources on te internet can be realized by implementing a flexible arcitecture tat allows dynamic scaling on te application level. Suc an arcitecture would allow to add resources from te cloud to an online-sop dynamically and on-demand. After referring to te underlying researc approac te paper discusses a partial cloud strategy and provides an example calculation sowing its benefits. Furtermore, a general arcitecture is sketced for implementing tis strategy into a system. Finally a flexible arcitecture is proposed for a sop to support integration of cloud resources on te basis of te general arcitecture. 2 Researc Approac and Scope of te Paper Te underlying overall researc project is based on a design science approac as suggested by Hevner et al. (2004) and Hevner (2007). Te paper at and focuses on motivating te relevance of te addressed researc problem and suggests a first sketc of an arcitecture tat migt elp solving tis problem. As design science "is inerently iterative" (Hevner et al. 2004, S. 87) and is organized along several design and test cycles our first step is to present te results of a first design cycle. In a next step a prototypical implementation will allow effective evaluation. In order to derive test data for a first evaluation and to furter substantiate te relevance of our researc we are currently analyzing workload data of a series of onlinesops. Some preliminary results are already included witin tis paper to back up our argumentation but are not te main focus ere. 3 A basic E-Commerce System Laudon and Traver (2009, p. 10) define e-commerce as "digitally enabled commercial transactions between and among organizations and individuals." According to Illik (2002, p. 131ff) an online-sop is te central system in e-commerce. Figure 1 depicts a basic arcitecture of today's e-commerce systems, wic is derived from our own analysis of typical systems and wic is also consistent wit Turban et al. (2008, p. 19-3ff). Te system usually consists of various intercon-

3 MKWI 2010 E-Commerce und E-Business 1291 nected subsystems. An online-sop is te core component tat implements te processes for selling goods and services and presents te system to users and customers. It is mostly realized as a multi-layered web-application wic is accessed by a web-browser. An online-sop obtains its master data from a content management system (CMS) and additional information like available stock of an article are fetced from te enterprise resource planning (ERP) or inventory management system. Tracking data is sent to a tracking system; orders are forwarded bot to te ERP system and, if needed, to a payment provider. Besides tat, a sop system can ave dependencies to furter systems, i.e. an external logistics system. Figure 1: Te Subsystems of a Basic E-Commerce System Te basic components of an online-sop are described below: Te Cart component olds a list of articles wic te user intends to buy. Tis information is usually stored permanently. Te Catalog component presents te offered articles to te user. Articles contain descriptive texts, pictures and various attributes. It is common to assign te products to categories. Te Order component implements te process of starting te business transaction. Te component forwards orders to te ERP system wic initiates te processing of te transaction. Te user interface (UI) is usually presented by means of a web-browser wic runs on a client macine. Te browser communicates wit te server-side by sending requests to a dedicated web server, wic forwards te requests for furter processing and delivers te results back to te browser. Te processing logic can be replicated and usually runs in application servers. Persistent data is stored in a database cluster.

4 1292 Georg Lackermair, Susanne Straringer, Peter Mandl 4 Suggested Strategy For small- and medium-sized businesses (SMBs) it is quite a difficult task to implement dynamic scalability into a web-based system. Running te wole application on own ardware would scale quite well, wen it comes to static scaling of a system. Yet its downside is revealed, wen an application is to be scaled down after a peak or in times wit just a little workload, as owned ardware generates costs, even if sut down. Terefore, outsourcing of te infrastructure by using cloud resources seems to be appealing, because in te cloud te computing capabilities can be adapted easily and dynamically. But te usage of external service providers as some major drawbacks: A survey among CIOs in Germany pointed out tat security concerns and probably evolving dependencies seem to be te most important reasons against te usage of computing capabilities via te internet (TecCannel, 2009). Te mentioned dependencies refer to te costs of canging tecnology and providers, wic is described as lock in by Saprio and Varian (1998, p. 106). Hayes (2008) empasizes transparency issues and Quality of Service (QoS) as major concerns wen it comes to Cloud Computing. Armbrust et al. (2009) provide a compreensive overview on problems involved in using tis approac in contrast to te oter references, tis work points to te problem tat providers operate on a eterogeneous legal basis. An appropriate strategy must take tese concerns into account: Critical components like te frontend web server and te database server may remain in-ouse, wile parts of te application are deployed remotely in virtual macines. Te needed infrastructure will be allocated from Infrastructure as a Service-providers (IaaS) wo offer virtualized macines for rent. To address te major concerns connected to Cloud Computing, a suitable IaaS-provider must meet several requirements. From a business perspective it is important, tat te pricing model is based on a low level of fixed costs. As te instances in te cloud will be online only for small periods of time, iger variable costs are acceptable, wile low or no fixed cost are desirable. Preferably an instance is paid for te ours online, witout any base fee. From a tecnological perspective, tere sould not be any restrictions about te system tat is running inside a virtual macine osted by an IaaS-provider. Tere could be restrictions on te operating system or installed software wic could cause migration problems and finally would contribute to a lock in. In addition to tis, te interface for activating virtual macines sould be publicly accessible and standardized. Tis again minimizes switcing costs. If tose requirements are met, a multi-sourcing strategy could be implemented, wic adds flexibility and decreases dependencies on a single provider (Wannewetsc, 2007, p. 150). In te following we discuss ow te major concerns related to Cloud Computing can be addressed in detail.

5 MKWI 2010 E-Commerce und E-Business Addressing Cloud Computing Concerns In te first run, we focus on te basic tecnical concerns about Cloud Computing, namely evolving dependencies on a provider, QoS-problems and transparency. 5.1 Evolving dependencies Some approaces like Google App Engine 1 require tat te osted application is programmed against a proprietary API. Furtermore, as data is stored on proprietary systems SMBs could fear to run into migration problems, once tey intend to cange te provider and find te data locked (Armbrust et al., 2009). Terefore, te components to be distributed in te cloud sould be programmed against standardized APIs and sould not store data locally (see 5.3). For te distribution of an application across network borders, te affected components must be able to integrate dynamically into an application te configuration may cange quite frequently, as te distributed components migt be deployed on different nodes, osted by varying providers. Besides a dynamic link in, standardized mecanisms for invocation of tose components, e.g. Web Services (Alonso et al., 2004, p. 152ff) sould be used. 5.2 Quality of Service In te described scenario it is assumed tat components in te cloud are added and removed frequently. Furtermore network connection between suc a component and oter system components can fail. Traditional clustering terefore provides state replication to andle server breakdowns. Across network boundaries, owever, tis does not seem to be reasonable, as te connections between te cluster nodes are slower, less available and ardly predictable wit respect to reliability and latency. As a consequence of tis distributed components sould be stateless, as suc components are easier to recover or migrate in failover situations (Brown, 2008, p. 525ff). 5.3 Transparency Small- and medium-sized companies migt want to keep control over persistent data and keep te backend system in-ouse. According to Kaufman et al. (2002) privacy of information is a very important aspect of data security. Terefore, data sould eiter be encrypted or not stored at all on macines in te cloud. Te components tat are running on macines in te cloud sould meet te same security level as components tat interact witin a closed network. Cacing supports tis requirement as tis makes persistent storage outside trusted data 1 ttp://code.google.com/appengine/

6 1294 Georg Lackermair, Susanne Straringer, Peter Mandl centers redundant. Furtermore, all communication wit te distributed components sould be encrypted, e.g. wit VPN tunnelling. In addition to tis, cloud components access rigts on backend systems sould be limited to read-only access. 6 An Arcitecture for Dynamic Scaling An arcitecture for a partial integration of external computing capabilities is depicted in Figure 2. Figure 2: An Arcitecture for Dynamic Scaling Te application needs to contain a component wic controls te cloud instances. Basically, tis means to switc on and sut down te instances. An instance as to register as an available node, wen te start-up is finised. Te cloud control also decides wen to add a new node or wen to remove a node from te application. Terefore, tis component must process information from various sources almost in real-time. Metods and models described by Menascè et al. (2000; 2004) provide a ric set of approaces for capacity planning. However, te concepts still need to be adapted to te specific situation of an automatic planning process. From te arcitectural sketc, te most important functional requirements can be derived: Link in: Wen a new node is added to te application, te superordinate node, e.g. te balancer needs to get notified about tis event to direct workload to te new node. Migration: Wen te decision is made to sut down a node, a mecanism must make sure tat remaining sessions get migrated to nodes tat remain active.

7 MKWI 2010 E-Commerce und E-Business 1295 Monitoring: Te cloud control needs to monitor subordinate nodes to get information about te resource utilization. Furtermore, a trend analysis of workload as well as ad-oc-analysis of tracking data elp to indicate workload evolution for te sort term. Planning: For forecasting of peak situations planning information needs to be processed. Tis information is used for long term workload evolution. Te implementation of te link-in and migration mecanisms seem to be tecnically feasible, as link-in could be based on common presence protocols like XMPP 2. Existing migration mecanisms for fail-over and load-balancing could possibly be adapted. For monitoring it as to be decided, wic information about resource utilization, workload evolution and tracking is available and ow it can be processed automatically. For determining te resource utilization all nodes could send information about CPU utilization or waiting processes to te cluster control. Furtermore, te web server could send alerts in case of a significant rise or fall of incoming requests. Ad-oc analysis of tracking data could elp to detect patterns in wic peak situations arise. Processing of planning data can be used to predict times in wic peaks or minimal workload are likely. For example, after te introduction of a new product it migt be probable tat te number of visitors rises significantly. It as to be examined, wic information can be provided by different plans and ow te data must be provided to be able to process te information computationally. 7 Example: Amazon Elastic Compute Cloud In order to estimate te economic benefits of a dynamically scaling arcitecture, total costs of ownersip (TCO) for te first year are calculated. Te calculation is based on te pricing model for Amazon Elastic Compute Cloud 3, wic is sown in Table 1. For sake of simplification te approac of using market prices for renting virtual macines seems to be fairly realistic. Table 1: Pricing Model for Amazon Elastic Compute Cloud On-Demand Reserved BEP Small 0.10$ per our 325$ $ per our 4643 ours Large 0.40 $ per our 1300$ $ per our 4643 our Amazon offers two different kinds of virtual macines: Small and large instances, wereas a large instance as approximately four times computing capabilities of a small instance. Terefore te example compares te flexible usage of four small 2 ttp://xmpp.org 3 ttp://aws.amazon.com/ec2/

8 1296 Georg Lackermair, Susanne Straringer, Peter Mandl instances to a single large instance. An instance can be rented on-demand, wic means tat te customer pays per our an instance is running. A reserved instance can be rented for a year for a base fee plus a relatively small ourly rate. Te Break-Even (BEP) is at 4643 ours. Anoter interesting aspect is tat a large instance causes exactly four times te costs of a small instance. For static scaling a large instance will be constantly running and terefore te price function can be defined as p s 0.12$ 1300$ were means te number of ours per year. In contrast to tis a dynamically scaled system can be composed of four small instances. One instance needs to provide constant availability, because it contains te web server and te cloud control component. Due to te pricing model, a reserved instance is most reasonable for tis purpose. Te additional instances are added on-demand. Te price function can be derived as n p d (0.03$ 325 $) 0.18n i i i were n is te number of utilization classes, wic classifies te overall resource utilization of all available computing resources. Te number of ours tat te system s utilization is classified in utilization class i is defined as i. For dynamic scaling some utilization classes ave to be defined: : 0 U : 0.25C : 0.5C : 0.75C 0.25C U U U 0.5C 0.75C C were U means te resource utilization and C te overall computing capability, i.e. CPU capacity. Te utilization class 25 means te number of ours per year in wic te overall computing capabilities are utilized up to 25 %, wereas 50 means a resource utilization tat is equal or greater tan 25 % but less tan 50 %, and so on. As we assume equal computing power in every node, eac load class represents a certain number of small instances needed to andle te workload. In tis example 25 demands one te constantly available reserved instance, 50 two, 75 tree and 100 four. Tis means tat for 50 one additional on-demand instance is needed, for 50 two, for 75 tree and for 100 four.

9 MKWI 2010 E-Commerce und E-Business 1297 Table 2: Comparison of Static and Dynamic Scaling Utilization profile TCO calculation p s p d delta 20 % 50 % 20 % 10 % $ $ % 30 % 40 % 20 % 10 % $ $ % 40 % 30 % 20 % 10 % $ $ % 50 % 35 % 10 % 5 % $ $ % Te results of various sample calculations are sown in Table 2. Te workload profiles in te table are assumptions based on our own observation of an onlinesop. Te relative low average workload is consistent to Armbrust et al. (2009, p. 10) wo suggest tat for many services te peak workload exceeds te average by factors of 2 to 10. Even if te workload profiles are estimated, te calculation reveals te potential efficiency of te proposed strategy. Moreover, first results of an analysis of a B2B e-commerce system indicate tat assuming a relative low mean CPU utilization is realistic. We analysed CPU-utilization of an application server tat logged every ten minutes over a period of 23 days and te classification of 3289 data rows as te following distribution: % 26.6% 0.3% 0.0% As te table sows (see column delta), for a relative low mean CPU utilization, dynamic application scaling would result in significant cost savings. 8 Application Arcitecture Tis part describes necessary canges in a sop's arcitecture to support te integration of cloud resources. Tis sketc is mainly based on te principles of serviceoriented arcitectures (SOA). For our work we reduce te ig-level approac of Ricter et al. (2005) to te tecnical level, wic implies loosely coupled components, e.g. Web Services as described in Turban et al. (2008, p ff). In our scenario, it is assumed tat service lookups do not occur on ig frequency a server instance looks up te needed services on start-up and later just on failure of te known provider. Tus, peer-to-peer-based SOA is proposed, as

10 1298 Georg Lackermair, Susanne Straringer, Peter Mandl longer latency times for service lookups are acceptable. Neverteless, any centralistic SOA approac would also be appropriate. Moreover, a dedicated service registry becomes redundant, wic reduces te systems dependency on te availability of suc a component. 8.1 Sop-Instances As mentioned in section 5, sifting to an extensively caced application is necessary for applying suc an arcitecture. Several solutions for distributed cacing already exist. Regarding te assumed fluctuation of server instances, for te described scenario, a P2P network could be used as a distributed cace mecanism, as P2P protocols are self-organizing and terefore can andle fluctuation in a network quite well. Wenever an application instance starts, it retrieves a uge amount of catalogue data from a database. A server could sare its caced contents wit oter server instances, witout involving te database server during te startup. Te new node will retrieve content data from an already running node. Tis prevents a dynamically scaled system from causing additional workload on te database server, wic is in general considered to be te bottleneck in e-commerce applications (Zang et al., 2004) Furtermore, self-organized cacing will reduce te workload of te backend systems, as querying for te initial instantiation of te caces descent as well as cace updates do not necessarily need to be propagated to every server instance. To meet te security requirements defined in section 5, read-only data can be distributed into te cloud. Tis could be catalogue data like categories, articles or te searc index. 8.2 Access to Backoffice Systems Current sop systems are networking wit various oter systems, e.g. CMS, CRM, ERP, DBMS and oters. For integration of tese applications service-oriented approaces are often used. Most common are Web Services or RESTful Services. For consuming a service an application looks up a central service registry for fetcing information about te service and invokes te service directly. For enanced flexibility, services can publis te corresponding service descriptions on a P2P network. Tis will reduce maintenance and configuration issues, wile adding availability to te lookup service. A drawback of a P2P-based lookup is a longer response time. In tis scenario tis seems to be acceptable as it is assumed tat te configuration of backend systems does not cange frequently and, tus, service lookups occur only on start-up and on configuration canges. Neverteless, a server-based lookup-service implementing e.g. UDDI 4 could also be used. 4 ttp://uddi.xml.org

11 MKWI 2010 E-Commerce und E-Business Load Balancing For providing load balancing and enanced availability many systems use redundant web servers. A front-side web server redirects incoming clients to different server nodes. HTTP clustering is usually set up wit static configuration, wic decreases flexibility. Te JXTA-based framework Soal can operate across network borders and terefore is a good coice, as JXTA applies principles of selforganization 5. If a system runs wit a single superordinate balancer, simple presence protocols like XMPP 6 can be used for te excange of presence information. Anoter possibility is to add a message queue to te balancer. 9 Conclusion and Outlook Te paper pointed out te benefits of a partial integration of cloud resources into an online sop for small- and medium-sized companies. Te conflict between rising energy costs, fluctuating workloads and continuously ig availability requirements will simply demand mecanisms tat enable automated and dynamic scaling of suc an application. Besides, largely underutilized servers cause unnecessary emissions. Preliminary results of an analysis of a B2B system underline te problem clearly: Over a period of 23 days te mean CPU-utilization was 19.6 % wit a maximum of 60 % and a minimum of 0.1 %, wile te standard deviation amounts 30 %. Tis means, tat te server was largely underutilized, wile te deviation indicates a ig fluctuation. Tis is supported by te fact tat 80 % of te daily requests were received in twelve ours, wile in te oter twelve ours only te remaining 20 % were received. Te steepest increase of 40 % points to te problem tat te server utilization can cange significantly witin a few minutes. A conclusion of tis study regarding dynamic scalability can be tat components tat are distributed on cloud resources require a sort start-up time. Tis means tat it is infeasible to load te full cace of e.g. catalogue data before being accessible. Ad-oc queries in te already running instances could determine te most requested data items and prioritize tose for cacing. For a deeper understanding of ow te integration of cloud resources affects an organization, more studies on te following subjects need to be performed. Cloud Computing: Te TCO calculation in tis paper is based on te Amazon Elastic Compute Cloud. To evaluate te economical benefits of te proposed strategy more providers ave to be examined in consideration of services, pricing model and tecnical integration into applications. Comparisons of major providers can be found in Rad et al. (2009) and Hayes (2008). In te next step, we will exam- 5 ttps://jxta.dev.java.net/, ttps://soal.dev.java.net/ 6 ttp://xmpp.org

12 1300 Georg Lackermair, Susanne Straringer, Peter Mandl ine te tecnical interfaces wit wic cloud providers expose te virtualized resources to customers to define a standardized way of managing tose resources. Automated Scaling: Just little is known about automated scaling. It is still not proven, ow precise top-down capacity planning is in practice and ow te data for e.g. forecasting business evolution can be determined and processed automatically almost at real-time. Obviously tis process sould demand less computational resources tan wat can be saved by dynamic scaling. Tus, a bottom-up approac seems to be appealing: Te cluster control would monitor all te nodes in te system and detects te situation in wic an additional instance is needed or an instance can be sut down. However, as te demand of computational capability sould be kept low, monitoring data cannot be transferred and analyzed in very sort periods. Tis conflicts wit te finding described above, tat te utilization can rise significantly witin minutes. It becomes obvious tat neiter of bot approaces provides satisfying results. Terefore, influencing factors ave to be studied in detail to combine te predictive approac wit te reactive one. Even if tere are some obstacles remaining towards a fully automated mecanism, tis paper sows te potential of dynamic scaling for small- and mediumsized companies wo cannot balance ardware utilization. Fully outsourcing into te cloud is not attractive, as tis creates dependencies. However, as te calculation in section 7 sows, a dynamically scaled application tat integrates cloud resources results in significant economic and ecological savings and reduces te mentioned dependencies. References Alonso G, Casati F, Kuno H, Maciraju V (2004) Web services: concepts, arcitectures and applications. Springer, Berlin, Heidelberg. Armbrust M, Fox A, Griffit R, Josep AD, Katz R, Konwinski A, Lee G, Patterson D, Rabkin A, Stoica I, Zaaria M (2009) Above te Clouds: A Berkeley View of Cloud Computing. EECS Department, University of California, Berkeley. UCB/EECS ttp:// Brown P (2008) Implementing SOA: Total Arcitecture in Practice. Addison- Wesley. Computerbase (2009) Riesiger Ansturm auf vergünstigtes Windows 7 (Update 2). ttp:// dows 7/2009/juli/riesiger ansturm windows 7/, visited: 2009/07/23. Cronicle M (2009) Das Windows 7 Pre-Order Drama! ttp:// 2009/07/16/das-windows-7-pre-order-drama/, visited: 2009/07/23. Hayes B (2008) Cloud Computing. CACM 51(7):9-11.

13 MKWI 2010 E-Commerce und E-Business 1301 Hevner A, Marc S, Park J, Ram, S (2004) Design Science in Information Systems Researc. MIS Quarterly 28(1): Hevner AR (2007) A Tree Cycle View of Design Science Researc. Scandinavian Journal of Information Systems 19(2): Illik, J (2002) Electronic Commerce. Oldenbourg Wissenscaftsverlag. Kaufman C, Perlman R, Speciner M (2002) Network Security: Private Communication in a Public World. 2 nd Edition. Prentice Hall PTR, New Jersey. Laudon K, Traver C (2009) E Commerce: Business. Tecnology. Society. 5 t Edition. Pearson International Edition. Menascé DA, Almeida VAF (2000) Scaling for E-Business. Prentice Hall PTR, New Jersey. Menascé DA, Almeida VAF, Dowdy LW (2004) Perfomance by Design. Prentice Hall PTR, New Jersey. Rad MP, Badasian AS, Meydanipour G, Delce MA, Alipour M and Afzali H (2009) A Survey of Cloud Platforms and Teir Future. In: Gervasi O et al. (Eds.) Computational Science and Its Applications. Proceedings ICCSA LNCS 5592: Springer, Berlin, Heidelberg. Ricter JP, Haller H, Screy P (2005) Serviceorientierte Arcitektur. ttp:// Informatiklexikon der Gesellscaft für Informatik. Sapiro C, Varian H (1998) Information Rules: A Strategic Guide to te Network Economy. Harvard Business Scool Press, Boston. Stal E, Krabicler T, Breitscaft M, Wittmann G (2008) E-Commerce-Leitfaden. ttp:// visited: 2008/05/20. TecCannel (2009) Cloud Computing scürt Angst vor Kontrollverlust. ttp:// tecnik/news/ /sicereitsbedenken bei cloud computing/, visited: 2009/07/23. Turban E, Lee JK, King D, McKay J, Marsall P (2008) Electronic Commerce A Managerial Perspective. Prentice Hall. Wannewetsc H (2007) Integrierte Materialwirtscaft und Logistik. Bescaffung, Logistik, Materialwirtscaft und Produktion. 3. Auflg. Springer, Berlin, Heidelberg. Zang Q, Riska A, Riedel E, Smirni E (2004) Bottlenecks and teir Implications in E-commerce Systems. In: Ci C-H, Steen M van, Wills C (Eds.) Web Content Cacing and Distribution. Proceedings WCW LNCS 3293: Springer, Berlin, Heidelberg.