IS303 Architectural Analysis Project

Re-architecting an Exchanges Web Application version ! beta " #anuary 0$%&

$! 'bjective
Students are required to demonstrate their understanding of concepts related to performance, availability, scalability, system architecture design, and exhibit practical skills in dealing with these issues on a Web application. For this project, a prototype Web application is provided, and students are required to modify its original design and demonstrate the re architected solution during the final presentation to meet certain non functional requirements. !ou will also get an opportunity to revisit concepts that you have learnt in several "S courses in this project such as ##$%, S&, &", %' and (omputational )hinking *if you have done that+.

! Project (i)eline
Week , $ctivities -elease of project requirements *this document+. o -elease of Scoring -ubric "n class. project briefing. %eploy prototype on individual laptops (ollection of switches / 0$1 cables from )$. 0ab 3 *Setting up a network+ -un prototype in private network 0ab , *)omcat clustering+. Set up project with tomcat cluster $llocation of interim demonstration tasks to teams by )$ 0ab 2 *0oad testing+. Start working on your project6interim demo. -elease of sample test scripts -un project with concurrent users (ontinue work on interim task and project (ontinue work on interim task and project -un some load tests, collect some data "n class. "nterim demonstration each team is to give a ,3 ,7 minute demonstration of its assigned task. *)his demonstration is worth 7: of your final marks.+ "nstructor may meet up with selected teams to check on progress. !ou will be notified if your team gets selected. "nstructors will let teams select slots for week ,2 presentation. <lease work with the "nstructor to select a slot. <roject design and architecture going on. 'ore 0$1 cables>..more time etc>.. *-emember to take some photos of your Work in <rogress for uploading to Facebook.+ )here are no in class lessons this week. Final project presentation and submission *27: of your final marks+. <eer review for project. -eturn the switches / 0$1 cables after the presentation to the "nstructors after your presentation. "nterviewing of selected students -elease of project grades
1

2 4

7 8 9 ; *recess+

= ,,

,2

,4 ,5

IS303 AA Project v2.2 (Term 2, 2013/14)

3! (he Story so *ar

!our client is a small brick and mortar stock exchange intending to *finally+ extend its trading operations to the Web. )he &xchange?s in house ") department has developed a simple Web application prototype to demonstrate functionality to management. )he prototype was developed using @S<6Servlet technologies and hosted on a single machine running )omcat with no database server. Aeing a rapid prototype with the main objective of demonstrating functionality, it was not designed with modularity, flexibility, extensibility, performance, reliability and scalability in mind. "n fact, it seems to be hacked together by various in house programmers who have not been properly trained in software architecture and design. $fter having obtained senior management?s nod for the functional requirements, the prototype has been turned over to your team for proper enterprise level architectural design, *re +development if necessary and hosting. Bsing the prototype as a guide, your client has requested that several non functional attributes be improved in your final system.

%! *unctionality o+ the Prototype

)he Web application provides the following main functionalities. ,. ,ie- static Web pages *for anyone+ 2. ,ie- current prices *for anyone+ 4. .og in/out *for authenticated users+ 5. 0uy shares *for authenticated users+ 7. Sell shares *for authenticated users+ 1! Sen2 to 0ac3 '++ice

)o help with troubleshooting, the following functionality is also implemented. 4! ,ie- un+ul+ille2 or2ers 5! En2 tra2ing 2ay

Figure , shows the various functionalities. %etails of each function follows.

IS303 AA Project v2.2 (Term 2, 2013/14)

*igure $6 7se 8ase 2iagra)

%!$ ,ie- static Web pages 0ike most Web sites, the &xchange provides several informational C)'0 pages to all visitors. (heck out the C)'0 pages in the staticpages folder of the prototype Web application. )here are a variety of C)'0 pages available of different siDes. Some of these pages are huge that may take a long time to appear in the client?s browser. !ou should preserve how these static pages look like since they have already been approved by the &xchange?s management. $nyone can view static pagesE there is no need for authentication. *)hese static pages can be viewed using http6//9hostIP6port:/Prototype/staticpages/9page;na)e:!ht)l after you have successfully hosted the prototype.+

%! ,ie- current prices 0ike static pages, anyone can view this page without logging in. Aut unlike static pages, this page shows, for each stock, the last price, the current *highest+ bid price and the current *lowest+ ask price. )his means that every time this page is refreshed in the browser, it may show different figures as new buy6sell orders come in. *)his current prices page can be viewed using http6//9hostIP6port:/Prototype/current!jsp after you have successfully hosted the prototype.+

%!3 .og in/out Bsers with accounts with the &xchange are able to log into the Web site and log off. When clients log in to perform a buy or sell operation, they provide a user "% and a password. )o keep things simple, for this project, there is no need to check if the user "%s and passwords are correctE you can simply assume that the user "%s and passwords provided are always correct. *)he login page can be viewed using http6//9hostIP6port:/Prototype/login!jsp after you have successfully hosted the prototype.+ "f a user attempts to view a FprotectedG page such as buy!jsp or sell!jsp directly by keying in the full B-0 to these pages, he may be redirected to login!jsp if he hasn?t been authenticated yet.
3

IS303 AA Project v2.2 (Term 2, 2013/14)

%!% 0uy shares #nly users who have logged in *i.e. authenticated users+ are able to buy shares. Shares are always transacted in lots of ,333 shares at this &xchange, and you can assume that the unit share price ranges only between H, and H,33 *including H, and H,33, with no cents+. When a user buys shares, the following information is important and needs to be sent to your Web application. the buyer?s user "%, the stock "%, the bid price for each share, and the date6time stamp of this request. Auyers cannot retract their buy orders once they have sent one in, and all buy orders will always be for ,333 shares *rather than a multiple of ,333+. &ach buy order will be queued in the Web application until it matches a sell order. $t the end of the trading day, all unmatched buy orders will be discarded. Since this is a small &xchange, there are only 4 types of shares to buy. S'B, 1BS and 1)B. *)he buy shares page can be viewed using http6//9hostIP6port:/Prototype/buy!jsp after you have successfully hosted the prototype.+

Aecause settlement of trades *i.e. payment for purchase+ is only done the following day, all FpurchasesG are made on credit. )he exchange imposes a credit limit of H,,333,333 per user which is reset at the beginning of each trading day. When a user enters a buy order, your system must ensure that the buyer?s daily credit limit is not breached. "f so, the buyer?s buy order is ignored and is not even placed into the queue. For example, a particular buyer has submitted 25 buy orders of ,333 S'B shares each at H53 per share. Ce has hence Fused upG H=83,333 of his credit, and is left with only H53,333 of credit for buy orders for the day. Ce then submits another buy order for another lot of S'B shares at a bid price of H73 per share *or H73,333 for ,333 shares+. Bnfortunately in this scenario, the system should not allow this new buy order to be submitted regardless of whether the previous 25 buy orders have been fulfilled, because the buyer?s credit limit of H,,333,333 will be breached if the last buy order goes through. Aesides showing the user an error message to notify him that his buy order cannot be processed, such buy orders need to be logged in a log file *rejecte2!log+.

%!< Sell shares #nly users who have logged in successfully *i.e. authenticated users+ are able to sell shares. Shares are always transacted lots of ,333 shares at this &xchange, and the unit share price ranges between H, and H,33 *including H, and H,33+. When a user enters a sell order, the following information is important and needs to be sent to your Web application. the seller?s user "%, the stock "%, the ask price for each share, and the date6time stamp of this request. Sellers cannot retract their sell orders once they have made a sell order. &ach sell order will be queued in the Web application until it matches a buy order. $t the end of the trading day, all unmatched sell orders will be discarded. *)he sell shares page can be viewed using http6//9hostIP6port:/Prototype/sell!jsp after you have successfully hosted the prototype.+

IS303 AA Project v2.2 (Term 2, 2013/14)

)he ask price is the lowest price a seller of a stock is willing to accept for a share of that given stock. #n the other hand, the bid price is the highest price a buyer of a stock is willing to pay for a share of that given stock. )he FcurrentG bid price is the highest bid price in the queue so far, and the FcurrentG ask price is the lowest ask price in the queue. "n order to match the hordes of buy and sell orders, the exchange starts with the highest bid and try to match it up with the lowest ask. "f there is a match, the transaction occurs at either the current ask or current bid price depending on whether it is a selling trade or a buying trade. $ Fbuying tradeG occurs when a match happens because of a new buying order. "n a Fbuying tradeG, the transaction price is the current ask price. $ Fselling tradeG occurs when a match happens because of a new selling order. "n a Fselling tradeG, the transaction price is the current bid price.

Cere is an example to illustrate these rules for a particular stock.

)im e 3 , 2 4 $ction $ makes a buy order for ,333 shares of S'B at bid price of H,36share A makes a buy order for ,333 shares of S'B at bid price of H,,6share ( makes a sell order for ,333 shares of S'B at ask price of H,26share. *no match+ % makes a sell order for ,333 shares of S'B at ask price of H;6share. *match between % and A. )his is a selling trade, and the transaction happens at the current bid price+ & makes a sell order for ,333 shares of S'B at ask price of H,26share. *no match+ F makes a buy order for ,333 shares of S'B at bid price of H,26share. *match between F and (. )his is a buying trade, and the transaction happens at the current ask price. 1ote that even though ( and & are both asking for H,26share, ( gets matched first because of its earlier time stamp.+ "n the buy queue $ *H,36share, tI3+ $ *H,36share, tI3+ A *H,,6share, tI,+ $ *H,36share, tI3+ A *H,,6share, tI,+ $ *H,36share, tI3+ A *H,,6share, tI,+ "n the sell queue (urrent *highest+ bid H,3 H,, (*H,26share, tI2+ (*H,26share, tI2+ %*H;6share, tI4+ H,, H,3 (urrent *lowest+ ask 16$ 16$ H,2 H,2 0ast price 16$ 16$ 16$ H,,

5 7

$ *H,36share, tI3+ $ *H,36share, tI3+ F *H,26share, tI7+

(*H,26share, tI2+ &*H,26share, tI5+ (*H,26share, tI2+ &*H,26share, tI5+

H,3 H,3

H,2 H,2

H,, H,2

)he current prices page should always reflect the correct last, current bid and current ask prices for each stock. !ou can refer to the following Web pages for a description of the Ftechnical termsG for trading. http.66daytrading.about.com6od6daytradingbasics6a6'arket<rices'ove.htm http.66daytrading.about.com6od6daytradingbasics6a6Aid$sk0ast.htm

%!1 Sen2 to 0ac3 '++ice $s an &xchange, your client?s job is to collect buy orders and sell orders and match them. #nce a match in price is found, a transaction is executed, and three things need to happen. *i+ )he successful transaction is logged in a text file on at least one of your servers. $ sample log file is provided in the prototype *)atche2!log+, and you must adhere to the format provided. )he respective buy and sell orders are removed from your system?s queues.
5

*ii+

IS303 AA Project v2.2 (Term 2, 2013/14)

*iii+

!our application sends information about the transaction *as in your log file+ to a remote Aack #ffice Server. !our application communicates with the Aack #ffice Server using J'0 Web services. Study the prototype to determine how this is done.

)he Aack #ffice Server will then contact the seller and buyer via email and snail mail about their successful transaction, and perform the necessary follow up activities *such as collecting payment from the buyer and paying the seller, adjusting their balances with the (entral %epository etc+. )his Aack #ffice Server is 1#) part of your system, but provided as a service by another vendor, so you do not need to know how it does its job. "t is of course important that the transaction information received by the Aack #ffice Server tallies with the information in your log file.

%!4 ,ie- 7n+ul+ille2 'r2ers )his page is used primarily for debugging and troubleshooting. "t shows the list of queued *i.e. unfulfilled buy and sell orders for each of the 4 stocks+, as well as the credit limit of each user "%. %o ensure that this Web page works and reflects correctly the current FstateG of your system. *)he view unfulfilled orders page can be viewed using http6//9hostIP6port:/Prototype/vie-'r2ers!jsp after you have successfully hosted the prototype.+

%!5 En2 (ra2ing =ay )his page is used to simulate the end of a trading day. Aasically when this page is accessed, the system Fcleans upG and prepares for the next trading day. For example, unfulfilled buy and sell requests are discarded as part of the Fcleaning upG process, and the Flast pricesG of each stock is reinitialiDed. *)he &nd )rading %ay page can be viewed using http6//9hostIP6port:/Prototype/en2(ra2ing=ay!jsp after you have successfully hosted the prototype.+

<! Available Resources

!our team will be provided with the following. ,. <rototype implementation of the system developed using )omcat which features all the functions required *Prototype+. 2. !ou need to set up a private 0$1 for your Web application so that your simulation will not affect the school?s network. &ach team will hence be issued one ,36,33 &thernet switch and some 0$1 cables. )hese are to be collected from your )$ *it is your responsibility to return it to him after your final presentation+. !ou are allowed to use your own switch6hub or more than one switch if you prefer to. 4. 0ab exercises. these will help you get up to speed quickly. !ou can download the following relevant tools.

IS303 AA Project v2.2 (Term 2, 2013/14)

1etAeans. http.66netbeans.org6downloads or any other @ava "%& *)he prototype application has been tested with 1etAeans 9.2 and )omcat 9.3.28 that comes with 1etAeans.+ K %o not run your experiments6demo using 1etAeansL )omcat Web Server *"mportant note. during your demonstration, you should 1#) be hosting your application on )omcat that comes with 1etbeans, but on an independent )omcat server. "n other words, your Web application should be running without your "%& open during your demonstration.+ Misual Studio.1&) 23,2 Bltimate edition *from %reamSpark+ to perform simulated client tests *For teams preferring to use @'eter to perform load testing+ @'eter. http.66jmeter.apache.org6downloadNjmeter.cgi . )here are a few useful tutorial videos on !ou)ube about @'eter as well.

1! >our (as3
!our team?s task is to study the prototype provided and to either modify it or build from scratch a new Web application to meet the non functional requirements described below. %o not modify the functionalities and look and feel of the Web pages in the prototype as they have already been approved by the &xchange?s management. !our final FliveG implementation will need to cater for. ,. *ault tolerance. )he prototype runs on a single physical server, which means that if that server goes down, your whole application goes down. !ou need to design your system so that your entire Web site does not depend on the availability of a single server only. "f you want to set up a cluster for your servers, any client should not be FawareG of any failure in your cluster *except for perhaps, a longer response time+. *i+ )hink about the various situations in which one of the servers fail *sudden loss of power, disconnected from the network etc.+ and how your system will react to each of these scenarios. !ou can simulate some of these failures during your demonstration. *ii+ "s it possible to automate a server restart in each case of failureO "t will be great if you can demonstrate a system with automated and seamless failover *the client will not be aware of any failures, and the system administrator will not need to intervene manually, and there should be a log file showing erroneous conditions that can be analyDed subsequently+. *iii+ "s there any single point of failure *S<F+ for your systemO !ou do not have to take into consideration network6switch failures, but do think about server failures. "s there any server in your system that is so critical that if it fails, your whole Web application is not availableO "f there is such a S<F, try to get rid of it.

2. *ast Response (i)es. -esponse time to different Web pages of your web site can be monitored using virtual test clients simulated by MS.net. For this project, there is no need to bother about network latency K what you need to improve is your Web application?s response time, with network latency assumed to be a consistent value. )here are various ways to improve response time, and you are allowed to refactor the code to achieve this objective
7

IS303 AA Project v2.2 (Term 2, 2013/14)

*remember to preserve the functionality and look and feel+. )here are three categories of pages that should run faster. *i+ -esponse time of the various static pages *ii+ -esponse time of the Fcurrent priceG page *iii+ -esponse time for the buy share and sell share pages 4. ?igh (hroughput. $s a market exchange, volume is as important as response time. !our application should be able to handle a significant number of concurrent requests. Bse your load tester to measure the rate at which your application accepts and processes incoming buy6sell orders. 1ote that response times *discussed above+ and throughput may be inter dependent K be aware of and discuss any tradeoffs involved. 5. ?ori@ontal scalability. !our Web application is expected to be easily scalable as the number of online users increase over time. !our team is expected only to focus on horiDontal scalability *scaling by adding more servers+, and not on vertical scalability *scaling by adding more physical resources to each machine such as -$'+. 7. Reliance on an external syste). !our Web application communicates with an external Web service provided by your Aack #ffice Server partner. )here is no guarantee that this Web service will be always upE in fact, your team has been warned that this communications gateway does suffer from periodic unscheduled downtime as your partner struggles with capacity issues. !our team has to make a decision as to what should be done in the event that your application is unable to communicate with the Aack #ffice Server during a Fsend to back officeG operation. Whatever the case, it is very important that the FfiguresG balance in the sense that all the transaction information is correctly sent over. )hat is, you need to ensure that by the end of each trading day, all the transactions in your log file match the information sent over to the Aack #ffice Server. $fter all, clients will be very unhappy if they are not informed if their buy6sell bid went through *-ecall that there were some system hiccups during Facebook?s "<#O+. %uring your demonstration, your assessors may check that the transaction data received by the Aack #ffice Server is consistent with your log file at the end of your trading period. )he occurrence of the end of the current trading day is simulated by visiting the en2(ra2ing=ay!jsp page *of course, this can be also automatically triggered by a clock+.

1! Reliability o+ transactions !our web site receives buy and sell orders, and your application needs to match them. )his is how it is done in the prototype. )he server maintains two lists. a buy order list, and a sell order list. )he relevant list is updated when a buy order or a sell order comes in. $fter queuing the new buy or sell order, the system checks if there is a match *of a buy order and a sell order+ for that particular stock. )his is done by scanning the 2 lists for the highest bid *buy order+ and the lowest ask *sell order+. "f the highest bid is bigger than the lowest ask, then you have found a matching buyer and seller for a stockL )he date6time stamp of a bid6ask is taken into consideration if there is a tie on the bid6ask price. the earlier order wins. #nce a match is found, the transaction is logged and sent to the Aack #ffice Server. )he relevant buy and sell orders are also deleted from the lists. )he stats that will be displayed in current!jsp, including the last price of the stock, are updated as well. When we talk about reliability of this system, it means that.

IS303 AA Project v2.2 (Term 2, 2013/14)

*i+

$ll buying orders and selling orders that have been successfully sent to the server are taken into consideration. 1o orders should be FlostG. For example. total number of buying orders successfully sent to the server I total number of buying orders in your unfulfilled buying order list P number of matched transactions *as recorded in your )atche2!log file+ P number of rejected buy orders *recorded in your rejecte2!log file+.

*ii+ *iii+

)he credit limit of each user should never be breached at any time during a FbuyG. When a series of buy and sell orders are placed in slow sequence, they should result in a fixed stable state *for example, if the series of requests in the table in section 5.7 are played out in a simulation using a load tester, the outcome of current!jsp, )atche2!log and rejecte2!log should be predictable and consistent. $t the end of the trading day, the contents of )atche2!log and the information sent to the Aack #ffice system are consistent.

*iv+

"t is very important to think about how each of these goals can be achieved if you have a clustered environment. Malidate empirically *using load tests+ that your system produces the same results when clustered and when running singly.

9. 'thers! "t is very important that you are able to demonstrate that you have achieved improvement in the abovementioned non functional attributes in a scientific and rigorous manner. For example, you need to show C#W you detected that the average response time to a particular static page has decreased for the same client load, with figures to support your claim. (redit will also be given to teams which can improve the other aspects of *i+ maintainability, *ii+ manageability and *iii+ extensibility of your Web application.

!ou should apply the theoretical concepts taught in the course, and find out how scalability, availability and performance can be improved in a real enterprise system *these may not be covered in the course+. Sometimes decisions about tradeoffs will need to be made. for example, between performance and availability. 1o marks will be awarded for effort spent on beautifying the user interface *i.e. Web pages+. !ou should focus on the non functional aspects instead. 1ote. we have decided to exclude the *very important+ non functional attribute of security from your scope. For example, there is also no need to encrypt communications between clients and the exchange server using SS0 *this is also always done for such Web applications involving financial liability+. Security is often antagonistic to other non functional attributes *for example, running the Web application over SS0 improves security by encrypting all the data transmitted over the network, but inevitably decreases performance+. For this project, you can ignore the security aspect of your Web application and focus on the other quality attributes. Aut do be aware that in real enterprise applications, security is often one of the most important quality attributes and often takes precedence over performance, availability and scalability.

4! Rules
,. !our final Web application implementation should be based on @S<6Servlet technologies hosted on )omcat running Windows, but we are generally open to your choice of alternative
9

IS303 AA Project v2.2 (Term 2, 2013/14)

technologies. So if your team wishes to select a different platform *e.g. $S< instead of @S<, or 0inux instead of Windows+ that you think will better serve your needs, please inform your instructor by week ;. Feel free to include a database server into your final solution if you think that that will assist you in meeting your objectives. 2. )he usual coding best practices should be adhered to. code comments, adherence to a coding standard. )he usage of relevant design patterns and industry best practice blueprints is encouraged. Aad programming practices such as having empty exception catch blocks *with no good reason for that+ will be penaliDed. )hink about what your program should do when an exception occurs and implement it. %o recall everything that you have learnt in the earlier programming and design courses, and apply the principles that you have *hopefully+ learnt. 4. %iagrams used in your documentation should be neat, clear and K if relevant K standardiDed *e.g. if you want to draw a B'0 deployment diagram, do follow the B'0 rule for deployment diagrams instead of inventing your own alien symbols+. $mbiguous diagrams gain you no marks because the assessors will not be able to understand them. 5. "t is permissible to get help from other teams6your )$ etc when completing your project, AB) !#B 'BS) $(Q1#W0&%R& the assistance that you have received in your demonstration6presentation. "f external resources are used *e.g. 4 rd party code6tools+, do cite sources. Bsage of code6resources downloaded from the Web without acknowledgement will be considered plagiarism, and will be severely dealt with.

5! Presentation/=e)onstration
)here are two milestones for deliverables. Wee3 4 interi) presentation *7: of final grade+ Week 9 will be a short interim version of the final presentation. "n the first half, each team will have $0 )inutes to present the results and explanation of one experiment. "n the second half, the team will set up a 2e)onstration of one fail over *failure of one machine+. !our demo will include running a load test and disconnecting one of the machines during the test. "nstructors may also look at the system manually during the test to check correct operation. Wee3 $ +inal presentation/2e)onstration an2 sub)ission *27: of final grade+ !ou will present your final solution to your instructors on week ,2. !ou should present your final deployment, then explanation each of your experiments and how they influenced your final system. !ou should also provide a comparison of performance between the original system and the final. !ou will also present the code for trade matching to show that no concurrency errors are possible and show the code to handle failures to update the backoffice. Finally you will run a load test to demo failover. )he instructors will select which machines to Sfail? and in what order. )ake note that we do not want to see Flive debuggingG *which is usually accompanied by panicked frenDy, cold sweat, and poor grades+ during your presentation, so rehearsals are really necessary for a smooth sailing demonstration.

For both the final and interim demo, you will be given a few test scripts with instructions on how to use them to test your web application. )he same test scripts will be used to perform FliveG load tests during your presentations..
10

IS303 AA Project v2.2 (Term 2, 2013/14)

&ach team will be given 4< )inutes for your final presentation, questions and demonstration. !ou !ll "!#$ t%!& t!'%t. Ae sure to arrive early to setup and be ready.

1ote that no servers will be provided for your demonstrations. which means that you will need to host your solution on your own laptops. $s previously noted, you do not gain additional points for demonstrating a short response time, but you need to demonstrate a SC#-)&- response time compared to the original prototype under same network conditions. !ou do 1#) get points for improving response time by decreasing network latency *for example, using a private wired 0$1 over wireless 0$1+, but you do gain points by showing that certain code or architectural changes have decreased response time of clients viewing your Web pages.

A! =eliverables
)he following are to be submitted in a BSA portable drive $) )C& S)$-) of your final presentation *we will return your drive after copying the contents+. ,. $ 2eploy)ent 2iagra) showing how your solution is hosted, with short notes justifying your deployment decisions, if necessary. 2. Full source co2e of your working system. <lace your code in the folder FsourceG. 4. $ rea2)e file *Word doc or <%F+ with clear instructions on how to deploy your solution. )his read me file is intended for system administrators who may not be familiar with your selected platform and tools. "nclude B-0s where additional software can be downloaded *for example, if you have installed )o2;cache, provide the version of )o2;cache used in your solution, the B-0 where it can be downloaded, and instructions on how to set it up to work with the prototype+. )o reduce the file siDe of your deliverables, please do 1#) include installers in your submission. 5. $ RolesAn2Responsiblites!p2+ file with full names of every team member, and brief information on the individual contribution and responsibilities of each member for this project. 0imit this to a single $5 page. 7. $ soft copy of any other )aterial used during presentation *e.g. <ower<oint slides+. <lace these artifacts in a folder called FpresentationG. <lace all deliverables in a folder called Rx)y where x is the section number and y is the team number of your team. )he following screenshot shows the files6directories which should be submitted by team , of section ,.

11

IS303 AA Project v2.2 (Term 2, 2013/14)

*igure 6 Sub)ission +or)at )eams will be penaliDed for missing deliverables or failure to prepare the deliverables as required *e.g. wrong folder names+.

$0! Bra2ing
)his project comprises 30C of your final score for this course *7: for interim demonstration, 27: for final presentation6demonstration6submission+. "t is important that all team members contribute fairly to the project. $ll team members should expect to be asked questions about the experiments and system. )he peer review form allows students to grade fellow team members on quality of work contributed, quantity of work contributed, technical expertise and general contribution. )he peer review results will be used to identify outstanding and under contributing team members within the team, and can be used to vary individual scores for the project. 1evertheless, teams are encouraged to surface teaming issues earlier on in the semester to instructors so that they can be monitored early and resolved.

10.1 Interim demonstration:

!ou will receive a score between 3 and 7 based on your demonstration. Rrading rubric. Scor e 3 , 2 4 5 7 %escription )eam is still in lala land. 0ittle work has been done, but we pity you enough not to award a Dero. Some work has been done, but team has difficulties getting the basic setup right. )eam has completed a major part of the assigned task, and answered some of the questions in their task description with empirical evidence. -esults are presented in a clear and systematic manner. )eam has completed the assigned task, and has answered most of the questions with empirical evidence. )eam has demonstrated good overall investigative skills and done a significant amount of experimental work to answer the questions in the task description.

10.2 Final Presentation:

)he following list is detailed in the grading sheet, posted separately. $ filled out grading sheet must be brought to the final presentation. %eliverables 7: quality of code, material, all required files and documents included

12

IS303 AA Project v2.2 (Term 2, 2013/14)

Fault )olerance 43: any single points of failureO Cow fast is failoverO "s restart simple and easyO Cigh <erformance 27: Cow much has been done to improve response times *page response times both static and especially dynamic+O Cow much has been done to improve throughput *number of pages, orders per unit time+O "s there convincing evidence of performance improvementO $re experiments valid, and support conclusionsO %o the experiments isolate the impact of one improvement at a timeO $re these posted on the wiki *see wiki note below+O &xplanation of &xperiments 23: Cow well can the team explain why the experiment results look as they doO (an the team identify the software and hardware causes for the resultsO Cas the team investigated the results in detailO )olerance of Aack #ffice faults 7: (an your application still work properly if the external system is downO When back office comes online, what is the delay to get records in synchO "s back office always correctly updatedO (orrectness of )ransactions ,7: $re order matching rules applied correctlyO $re there any concurrency errors *executing order multiple times, wrong price, crossed markets, violated credit limits, etc+O %o local logs match back office logsO $ny orders droppedO #thers up to P 7: $nything else especially awesome *or terrible+.

10.3 AA Wiki:
$ll teams will post their experiment results on the $$ Wiki. $nd all teams are required to write a review of one experiment done by another team *more may be required if the first does not meet expectations+.

13

IS303 AA Project v2.2 (Term 2, 2013/14)

Appen2ix A6 Running the Prototype

)he prototype can be easily executed and edited using 1etbeans 9.2 *with $pache )omcat 9.2.29+, although you are free to use any other @ava "%& you prefer. #btain the prototype.Dip file from e0earn, and unDip it to your hard disk "f you have 1etbeans 9.2, select, File#pen <roject from the menu, and navigate to the location on your hard drive where you downloaded your prototype. (lick on the green FplayG button on the icon bar at the top. )he web application will be hosted on the test version of )omcat and in2ex!jsp will be displayed. !ou can try out the various pages to check the functionality of the system. &xpand FSource <ackagesG at the left <rojects panel to view the Exchange0ean!java file. )his file contains most of the Fbusiness logicG of this application and needs to be studied carefully. "f necessary, change the DA(8?;.'B;*I.E and RE#E8(E=;07>;'R=ERS;.'B;*I.E constants in Exchange0ean!java *do you think it?s a good idea to Shard code? a full path name like this in a Web applicationO+ !ou will need to glance through each @S< file to get an idea of what each does. %o remember that for your final presentation, you need to host your Web application in )omcat properly and not run a test instance of )omcat from the 1etbeans "%&L

14

IS303 AA Project v2.2 (Term 2, 2013/14)

Appen2ix 06 So)e 7se+ul Re+erences

"S434 0ab ,. (overs clustering of 2 )omcat servers using modNjk "S434 0ab 2. (overs load testing of a Web application using Misual Studio )eam System 'y ST0 (luster. http.66dev.mysql.com6downloads6cluster69.3.html *"f you intend to perform database server clustering using 'yST0, you will need to get the 'yST0 (luster editionE the (ommunity Server edition does not support clustering.+ Bseful book on 'yST0 (lustering. F?igh Per+or)ance DySE.G *2nd edition+ by SchwartD, Uaitsev, )kachenko, Uawodny, 0entD and Aalling. S'B students have access to the online version of this book via the S'B library Website. $ brief overview of )omcat clustering *what are sticky sessionsO What is session replicationO+. http.66www.easywayserver.com6tomcat clustering.htm )wo quick write ups about general concepts. http.66www.datadisk.co.uk6htmlNdocs6javaNapp6tomcat86tomcat8Nclustering.htm and http.66www.vicconsult.com6tips6apache tomcat load balance session replication.html

15

IS303 AA Project v2.2 (Term 2, 2013/14)

Appen2ix 86 Presentation 8hec3list

o o $ll deliverables in section = placed on thumb drive before presentation Slides showing response time include variance *points awarded for including, and deducted if missing+ (ode for transaction matching and for back office opened in development environment for instructors to view it. 0oad test, including buys6sells, ready to run *Vusers K should not create errorsE time W43 minE bids6asks should be random+ o o %atabase set and ready to go

<resentation $genda in the following order. o o o o o o o (over page with Rroup J, )eam ! *replace x, y obviously+ #verview of System and %eployment -esults of performance experiments 'iscellaneous other cool stuff Show code for handling back office and explain Show code for transaction matching and explain -un load test K instructors will direct failures

16