A Tool to Automate the Sizing of Application Process for SOA based Platform

Transcription

1 A Tool to Automate the Sizig of Applicatio Process for SOA based Platform Debajyoti Mukhopadhyay Juhi Jariwala Payal Iai Departmet of Iformatio Techology Departmet of Iformatio Techology Departmet of Iformatio Techology Maharashtra Istitute of Techology Maharashtra Istitute of Techology Maharashtra Istitute of Techology Pue, Idia Pue, Idia Pue, Idia Sheetal Bablai Departmet of Iformatio Techology Maharashtra Istitute of Techology Pue, Idia Sushama Kothawale Departmet of Iformatio Techology Maharashtra Istitute of Techology Pue, Idia Abstract SOA (Service Orieted Architecture) is a loosely-coupled architecture desiged to tackle the problem of Busiess/Ifrastructure aligmet to meet the eeds of a orgaizatio. A SOA based platform eables the eterprises to develop applicatios i the form of idepedet services. To provide scalable service iteractios, there is a eed to maitai service s performace ad have a good sizig guidelie of the uderlyig software platform. Sizig aids i fidig the optimum resources required to cofigure ad implemet a system that would satisfy the requiremets of BPI(Busiess Process Itegratio) beig plaed. A web based Sizig Tool prototype is developed usig Java APIs(Applicatio Programmig Iterface) to automate the process of sizig the applicatios deployed o SOA platform that ot oly scales the performace of the system but also predicts its busiess growth i the future. Keywords SOA(Service Orieted Architecture), SOA Platforms, SOA Sizig, Sizig Tool prototype, Java Sizig API. I. INTRODUCTION I today's e-world, where compaies ad orgaizatios carry out most of their busiess over the iteret, software architectures attempt to deal with the icreasig levels of complexity. As the level of complexity cotiues to asced, traditioal architectures do ot seem to be capable of dealig with the curret problems such as the eed to respod quickly to ew requiremets ad allow better ad faster itegratio of applicatios. As web techologies ad related busiess eeds evolve, especially isolated service requests/compoets, it puts a ew demad o the software architecture beig used. SOA beig a platform idepedet architecture, it provides viable workig solutio to implemet dyamic e-busiess. It eables distict software applicatios to exchage iformatio ad commuicate with other applicatios i the etwork without huma iteractio ad without the eed to make chages to the uderlyig software program itself. A service-orieted architecture [1] is essetially a collectio of services, amog which the commuicatio ca ivolve either by simple data passig or it could ivolve two or more services coordiatig some activity, requirig meas of coectig services to each other. The first service-orieted architecture i the past was with the use DCOM or Object Request Brokers (ORBs) based o the CORBA specificatio [2]. To uderstad service-orieted architecture it is importat to have a clear uderstadig of the term service. A service [3] is a fuctio that is well defied, self-cotaied, ad does ot deped o the cotext or state of other services. Figure 1 illustrates a basic serviceorieted architecture wherei a service cosumer seds a request to a service provider ad the service provider replies back with a respose. Commuicatio via messages promotes iteroperability, ad thus provides adaptability beefits, as messages ca be set from oe service to aother without the cosideratio of how the service hadlig those messages has bee implemeted. SOA makes it easy for computers coected over a etwork to cooperate with oe aother. Every computer ca ru a arbitrary umber of services, ad each service is built i a way that esures that the service ca exchage iformatio with ay other service i the etwork without the eed of makig chages i the base program. Fig 1. Basic Service Orieted Architecture The key characteristic of SOA is that these idepedet services with stadard iterfaces ca commuicate with other services i a way, without the

2 service havig forekowledge of the callig service ad of the uderlyig platform implemetatio. SOA based platforms are developed to facilitate the itegratio of busiess processes deployed o various eterprise applicatios. Oe importat requiremet is to esure that the deployed system satisfies the performace objective. To help the architects ad busiess aalysts cotrol the cost of a BPI solutio, it is ofte required that the resource cosumptio is estimated before the system is developed ad deployed. That is, sizig of the platform eeds to be carried out. Cosiderig the limitatios of the existig sizig tools available ad to automate the sizig process, a web based sizig tool prototype is proposed. It determies the required hardware alog with its topology before deployig the applicatios, takig ito cosideratios the best practices. Sectio 2 explais the literature survey carried out. Sectio 3 provides a complete view of the proposed tool ad its developmet i phases. Sectio 4 describes the implemetatio details ad results. Sectio 5 covers the practical applicatios of the prototype. Sectios 6, 7 preset the future scope ad coclusios respectively. a. HP s(hewlett-packard) Performace ad Sizig Guide [7] provides iformatio ad recommedatios about desigig ad cofigurig the UNIX eviromet to ru its Admiistratio UI(User Iterface). Although beig API based, some of its operatios do ot rely o the API. b. Performace Tuig ad Sizig Guide for SAS Users [8] gives basic uderstadig of how to aalyze ad apply tuig chages to SAS applicatios ruig o SUN UltraSPARC hardware platform. c. Itel s Server Sizig Tool [9] provides its customers with a sizig solutio i the form of two-socket servers or four-socket servers based o various workload coditios i their ERP(Eterprise Resource Plaig) eviromet. However, beig limited to a particular eviromet, it may ot be able to size servers belogig to other eviromets. The objective of the sizig prototype discussed i this paper is to preset a geeralized, API based tool for SOA platforms costructed usig a lightweight UI framework. II. EXTENSIVE TECHNICAL RESEARCH Followig the global ecoomic growth, firms carryig out their busiess over the web look for iovative ways to cut dow the techical costs ad maximize its value, i order to acquire a competitive hold o the IT(Iformatio Techology) market. Growig acceptace of pioeerig techologies makes terms like SOA, web services, sizig, etc. big buzzwords i IT. Owig to their importace, the techical research phase led to the study of followig topics: 1. Web Services ad its applicatios Web services are ot tied to ay operatig system or programmig laguage. Alog with supportig coveiet ad o-demad commuicatio, they provide a strog iterface for collectio of operatios beig accessed o the etwork. It has applicatios i cloud computig, wherei a Service Cosumer ca choose aright service from a group of similar web services. [4] Web services are also used i query optimizatio techiques to come up with faster ad efficiet algorithms to retrieve data from databases. [5] 2. Applicatio of SOA The telecommuicatio idustry focuses o deliverig the best quality services to its users. To keep the system up ad ruig at its best, capacity plaig of the services ad of the platform is carried out to be able to hadle icreasig icomig trasactio requests with allocated services [6]. 3. Existig Sizig Tools ad Guides Presetly, there are sizig tools ad sizig guides available i the market. Some beig precise to solvig a particular domai problem whereas some beig specific to certai products oly. III. PROPOSED WORK Curretly the process of sizig a SOA platform is performed by referrig the available documets ad related paper work. But may a times, customers are uable to uderstad it or do ot have access to such legal documets. Also, filterig what data is useful for the ed-user from the historical data is a tedious task. Havig a automated process would take the sizig process oe step up o the sizig ladder ad overcome the above metioed restrictios. Therefore, we have come up with a sizig tool prototype to provide meticulous hardware recommedatios for the applicatios ad services deployed o SOA based platforms. This tool comes up with sizig suggestios ad implemetatio details accordig to which a durable ad robust system ca be developed. Also resources ca be utilized i a competet ad well-orgaized way. This i the log ru esures legtheig life of the hardware as well as reducig maiteace ad repairs cost. The sizig model is costructed i three phases, testig ad aalysis phase, API geeratio phase ad UI(User Iterface) phase. Each of these phases is described below: A. Performace Testig ad Aalysis phase Simple applicatios are deployed o the AMX platform ad tests are coducted usig differet performace testig tools. These tests are performed to study how the system performs whe load o the deployed applicatios is varied. Meaigful data is collected from these tests ad aalyzed. B. API geeratio phase The aalyzed data is the used to determie a relatio betwee the performace parameters i the form of equatios. A algorithm is built usig these equatios. Further, this algorithm forms a basis of a geeralized Java based API. APIs ca be easily modified ad reused.

3 C. Froted UI phase To provide the ed user a easy ad user friedly way of performig the sizig task, a lightweight UI is costructed to give a visual feel of their system's performace. Followig diagram shows the visualizatio of the sizig tool prototype: B. Testig Methodology This sizig framework aims to put forth its sizig summary i the form of 3 stadard system recommedatios heavily used i productio eviromets, amely, medium system, large system ad performace lab system. The hardware cofiguratio of these systems is as follows: Table 1. Hardware Cofiguratios Fig 2. Visualizatio of Sizig Tool Prototype IV. IMPLEMENTATION A. Experimetal Setup: TIBCO ActiveMatrix(AMX) is a platform provided by TIBCO for developig ad deployig distributed SOA based applicatios. Usig this platform, eterprises ca rapidly desig, implemet, ad test applicatios, deploy them to their operatig eviromet of choice ad moitor ad maage the applicatios ed-to-ed. There are various parameters like type of service, payload(request ad respose), cocurret users, throughput, etc. that eed to be take ito cosideratio while sizig this JAVA based platform. To obtai relatio betwee these parameters ad to moitor how system resources are utilized if these parameters are assorted, various performace related load tests are coducted o this platform. Iitially applicatios are deployed o the platform. Each applicatio is assiged a idividual port umber where it ca receive requests ad process its task accordigly. Various tools are used to geerate load tests o those applicatios. Durig load tests performace parameters like CPU utilizatio, heap, etc. required by services are observed of the respective JVM. Type of System No. of Processors No. of Cores Frequecy (GHz) RAM (GB) Medium Large Performace Lab All tests ad experimets are coducted o the performace lab system i.e. o a logical 24 core machie. Cosiderig several variable parameters, the task of deployig services ad makig them ru efficietly is very complex. Tests are performed by simulatig real customer scearios that meet performace requiremets. To geerate uderstadable results, aalysis is coducted i the followig steps: Step 1: Same load tests are carried out o each of the three systems metioed above ad depedig o results obtaied from these tests relatio for CPU utilizatio ad memory usage betwee these systems is derived for medium system ad large system i terms of performace lab system. Step 2: All the further load ad stress tests are carried out o the performace lab system ad values for medium ad large system are geerated accordig to the relatio geerated i step 1. Step 3: Load tests are performed to fid relatio betwee all iput parameters. Scalability aspects ivolvig the memory ad CPU capability ad features are also tested. Step 4: Usig results of all load tests ad relatio betwee parameters obtaied i step3, graphs are plotted ad equatios are derived for hardware resources required by services. Step 5: The equatios obtaied are fie tued by extrapolatig the values ad further validatig them. This helps i geeratig more accurate results. C. Kapsack s Algorithm Fig 3: Experimetal ad Testig Setup The 0/1 Kapsack Problem [10] is stated as follows:

4 Give a set of kids of items labelled from 1 to, havig a weight w ad value v associated with each item respectively, determie the maximum umber of items to be icluded i a collectio so that the total weight is less tha or equal to a give limit, say W ad maximize the total value as much as possible. where, x j is j th service v j is type of j th service w j is CPU utilized by j th service W is maximum allowed CPU% utilizatio per machie This ca mathematically be represeted as bellow: maximize v j x j subject to w j x j W x j {0,1} The kapsack s problem is further classified ito the Bouded Kapsack Problem(BKP) ad the Ubouded Kapsack Problem(UKP). I BKP, x ca take up values ragig from 0 to some costat whereas i UKP, there is o restrictio o the value of x except that it should be a o-egative iteger. I order to haress the hardware ad software resources i the most efficiet way, we chose the Ubouded Kapsack algorithm ad implemeted it i the followig maer: Let curret_machie_cpu=0,curret_machie=1 for i from 1 to umber_of_services do if curret_machie_cpu+cpu_of_i th _service<w deploy service o curret_machie curret_machie_cpu+= cpu_of_i th _service else for j from i+1 to umber_of_services do if curret_machie_cpu+cpu_of_j th _service<w deploy service o curret_machie curret_machie_cpu+= cpu_of_j th _service ed if ed for ed if if curret_machie_cpu>=w distribute services amog the odes o that machie switch to ext machie ed if ed for The above algorithm ca mathematically be represeted as show below: maximize v j x j subject to w j x j W D. Sizig API To give the best ad optimum hardware recommedatio to the ed user, this tool summarizes its solutio usig sizig API (Applicatio Programmig Iterface). This API is developed usig the Kapsack algorithm ad mathematical equatios that forms the backboe of this web based tool. As there are ew hardware cofiguratios cotiuously evolvig i the idustry, it will be required to make chages i stadard server cofiguratios cosidered (as explaied i sectio 3.B.) for the output of our tool. With sizig API, these chages ca be evisaged easily without the eed to chage the code ad hece it ca be exteded to be the uderlyig computatio for sizig of other SOA based products. The followig code sippet represets oe part of the API costructed: Fig 4.Sizig API E. System Workflow Customer priorities vary depedig o the criticality of applicatios. While some applicatios are critical because of their payload, some are critical due to large umber of cocurret users. However, we eed to cosider the combied effect of these factors while desigig the sizig solutio. Therefore the iput parameters are broadly categorized ito two sectios, amely, deploymet time iputs ad rutime iputs. Deploymet time iputs iclude umber of services to be deployed, implemetatio ad bidig type of those service(s). Whereas, the Rutime iput iclude workload type, cocurrecy, throughput ad payload of the service(s). The user is also give the optio to eter his

5 choice of architecture i.e. either Sigle or Distributed. These iputs are classified ito two fragmets maily to furish the users with two levels of sizig outputs. The output of the first level gives a deploymet time sizig suggestio to the customers. That is, the amout of hardware required to oly deploy the specified umber of services. I the ext level, the output suggested by the tool also cosiders the rutime values alog with the deploymet values. The tool provides a summary page which collates all the iputs give by the customer, ad eables them to trace back ad chage the values or optios if required. Followig flow chart shows workig of the system: Alog with this, the tool also suggests the kid of architecture that the busiess veture must acquire, to upgrade its operatioal performace. The accuracy of the sizig summary geerated by the tool depeds o the iput provided by the customers, i.e. more the iputs provided, better is the footprit created ad lesser is the offset preset i the output values. The followig paragraphs give a short descriptio of topology diagrams, performace graphs ad ifrastructure diagram respectively. The topology diagram portrays the iteded umber of machies alog with their cofiguratio, eeded to deploy the services ad also idicates how may services should be deployed o each machie. If the computed umber of machies comes out to be very large, the customer is recommeded to switch to the ext larger cofiguratio. Followig figure represets a topology diagram for a large system implemetatio. Assumig 10 services are to be deployed o a platform like AMX, the diagram would look like this: Fig 6. Topology diagram for AMX platform Fig 5. Flowchart of system workflow F. Results The sizig tool adheres to a mathematical modellig approach which delivers a solutio based o the equatios obtaied from testig ad aalysis phase. The results geerated are i the form of topology diagrams, performace graphs ad ifrastructure diagrams for all the 3 system recommedatios i.e. medium system, large system ad performace lab system. This kid of compariso gives a pictorial view to the customers suggestig which system implemetatio they should adopt that would best maximize their available resource utilizatio. The user also has a added beefit of dowloadig the summary report. This comprehesive report gives all the required iformatio i detail to set up the system. For architects ad aalysts, such reports come hady i determiig how resources are to be allocated ad how much of the hardware will be required to build the system. Performace graphs play a very importat role i depictig how the system is curretly operatig ad to what extet it ca cotiue to perform well. They also predict the poit upto which the performace of the system could be scaled. Followig graph displays how CPU utilizatio of a machie icreases with icrease i the umber of services. The red regio idicates that performace of the machie would degrade if the umber of services deployed o that machie goes above a certai value, 12 i this case. Fig 7. Performace graph The ifrastructure diagram gives a blueprit of how the various compoets required to establish the setup

6 are coected to each other ad how they commuicate with oe aother. Followig diagram shows a AMX specific ifrastructure diagram. VI. CONCLUSIONS I a era of fast chagig busiess requiremets, more ad more SOA based platforms are emergig day-byday. It is oe of the architectural styles beig adopted by the upcomig eterprises due to its key features such as service orietatio, iter service commuicatio via goverace, uderlyig techology idepedece, etc. To make the most of this type of architecture, it is essetial to carry out sizig of applicatios o such platforms to determie hardware requiremets ad performace details before actual implemetatio of the system. This ot oly makes the system resiliet but also dimiishes the failure costs that may arise due to dyamically chagig busiess processes. The TIBCO sizig tool aims at givig a automated solutio to the sizig problem with the help of extesible UI ad core API. Fig 8. Ifrastructure Diagram VII. REFERENCES V. PRACTICAL APPLICATION 1. I a eviromet, where orgaizatios are relyig o SOA based solutios to solve their complex IT (Iformatio Techology) issues, a Sizig Tool will act as a catalyst by determiig the amout of hardware that will be eeded to establish a stable ad fault tolerat system. Havig a automated ad accurate tool to carry out the sizig process mitigates the risk of system breakdow ad reduces the overall cost as well. 2. The sizig tool acts i accordace with the equatios ad algorithms to come up with realtime system cofiguratios that ca be put to effect. 3. This is a research orieted sizig solutio beig developed wherei the mathematical equatios formulated to arrive at sizig requiremets ca be coverted ito a geeralized mathematical model which the ca be used to size other similar SOA platforms. 4. This web based tool is based o a geeralized sizig API which resembles SaaS(Software as a Service), i.e. the same API ca be exteded to carry out sizig operatios o other products ad applicatios elimiatig the overhead of implemetig the algorithm from scratch. 5. I compariso to the curretly available sizig tools i the market, this tool is build usig a lightweight UI(User Iterface) framework which makes it more reactive ad useriteractive. It also provides ed-to-ed sizig solutios for deploymet as well as rutime requiremets. [1] ml [2] [3] Raghu R. Kodali, 2005, A itroductio to SOA ( (06/13/05) [4]Debajyoti Mukhopadhyay, Falgui Chathly, Nagesh Jadhav, 2012, QoS Based Framework for Effective Web Services i Cloud Computig, I Joural of Software Egieerig ad Applicatios, Scietific Research, USA, Vol.5, No.11A. [5] Debajyoti Mukhopadhyay, Dhaval Chadaraa, Rutvi Dave, Sharyu Page, Shikha Gupta, 2012, Query Optimizatio Over Web Services Usig A Mixed Approach, I The Fourth Iteratioal Coferece o Web & Sematic Techology, WeST 2012 Proceedigs, Cheai, Idia; Spriger-Verlag, Germay; July 13-15, 2012; pp ; ISSN , ISBN [6] Masykur Marhedra, 2011, SOA i the Telco Domai Part II: Capacity Plaig of SOA-Based Systems, I Service Techology Magazie, Issue LIV, September [7] rc- 162/164799/1/Performace%20ad%20Scalability%20G uide.pdf [8] William Kears, Tom Keefer, 2003, SUGI 28, Seattle, WA, March 28, [9] [10]David Pisiger, Ph. D. thesis, 1995, Algorithms for Kapsack Problems, I Departmet of Computer Sciece, Demark. [11]Sathosh Kumara, Te-Kai Liu, Hui She "A Capacity Sizig Tool for a Busiess Process Itegratio Middleware"