Team 4

Project Page

17-654: Analysis of Software Artifacts

TEAM #4 - METAPHOR

                    Team |Team Roles |Project Title |Baseline Application Description |
                    Configuration |Third-Party Software |Baseline Application Features |
                    Reliability Requirements |Real-Time Requirements |Performance Requirement |
                    Baseline Application| Fault-Tolerance Baseline | RT-FT | Performance

1. Team

Daehyun Jung   :  djung@andrew.cmu.edu

Huiyeong Choi :  hchoi1@andrew.cmu.edu

HyoungielPark  : hip@andrew.cmu.edu

Inhong Kim      :  ihk@andrew.cmu.edu

Jungjun Suh     : jjsuh@andrew.cmu.edu

2. Team Roles

 

Jung

Choi

Kim

Suh

Park

Environment setup

 

 

 

 

x

Overall management

X

 

 

 

 

Application GUI (Coding)

 

 

x

 

 

Back-End ( LDAP) (Coding)

 

 

 

x

 

Server Module (Coding)

 

x

 

x

x

Client Module (Coding)

 

x

 

 

x

Testing

X

 

 

 

 

Real time analysis

 

 

x

 

 

Reliability analysis

 

 

x

 

 

Performance analysis

 

x

 

 

x

Presentation

X

x

x

x

x

Documentation

X

 

x

 

 

Architecture

X

x

x

x

x

 

3. Project Title

Human resource management system

 

4. Baseline Application Description

This is unified human resource management system for headhunting agencies.

 

5. Configuration

1.      Middleware: CORBA

2.      Operating system: Windows 2000(XP)

3.      Language: Java

 

6. Third-party software, if any (databases)

1.      Repository: SunOne LDAP

2.      ORB: JDK 1.4

3.      IDE: vim

4.      Configuration management: CVS

5.      LDAP API : Netscape LDAP Java API

 

7. Baseline Application Features

A client agency can sign up for being a member of head hunting association.

The association can provide different services to a client agency based on the level of privilege.

Client agency can retrieve applicants information that can be accessible with its privilege.

Client agency can make an applicants information invalid when the applicant want to make his information unavailable.

 

8. Reliability Requirements

If the process is down, the process can be recovered within 5 seconds.

If the server machine is down, the backup server can replace the original server within 5 seconds.

 

9. Real-time Requirements

1.      Authentication is done within 5 seconds

2.      First packet of inquiry result arrives in 5 seconds

3.      The entry changed by a client should be available to other clients within 2 seconds. The change by some clients should be reflected to another client within 2 second.

10. Performance Requirements

1.      50 concurrent users

2.      Max 500 entries per inquiry

3.      5 transactions per second

 

** The numbers are subject to change.

 

 


 

11. Baseline Application

   Interfaces : View

   Current Architectue :  View

   UseCases : View

   TestCases : View

   Downloads       

Baseline IDL

SourceCode 3.0

download

 (16 Mar 2004)

Baseline Application

SourceCode 3.0

download

 (19 Mar 2004)

 


 12. Fault-Tolerant Baseline Application ( Mar 16, 2004)

    Basic FT design

  * : Replication Manger

  ** : DB for retain status information servant

  *** : Fault detection and Switch to backup server

       

 

  • User ID : used for re-authentication and Client ID
  • User Password : used for re-authentication
  • User Level : user level is actually not necessary but decided to be saved for short recovery time
  • Operation ID : used for recovery of update-transaction failure
  • Transaction ID : used for recovery of update-transaction failure

       

        Test by operations ( bulkSearch, entrySearch, entryUpdate)

       (1)  bulkSearch 

  1. userLogin operation execute : user login with id and password
  2. Server down : main corba server down or crash
  3. bulkSearch : trying bulkSearch operation
  4. failover : replica is activated with the same state of the main corba server

(2) entrySearch

  1. userLogin operation execute : user login with id and password
  2. Server down : main corba server down or crash
  3. entrySearch : trying entrySearch operation
  4. failover : replica becomes activated with the same state of the main corba server

(3) entryUpdate

  1. userLogin operation execute : user login with id and password
  2. entryUpdate: update operation start forward LDAP server and data is updated
  3. Server down : main corba server downs before returning success message to client
  4. failover : replica becomes activated with the same state of the main corba server and return success message to client

CVS Path for source code : implementation for FT ( Mar 16, 2004)

IDL

/mse/17654/team_4/AnalysisClassProjectStage2/idl/BasicTest.idl

Server side :

/mse/17654/team_4/AnalysisClassProjectStage2/src/server/Server.java

/mse/17654/team_4/AnalysisClassProjectStage2/src/server/LDAPImpl.java

/mse/17654/team_4/AnalysisClassProjectStage2/src/replica/Repserver.java

Client side :

/mse/17654/team_4/AnalysisClassProjectStage2/src/client/Client.java

Application with FT

SourceCode 3.0

download

 (19 Mar 2004)

(CVS location)

      /mse/17654/team_4/AnalysisClassProjectStage2/src/Repman/PIDReader.java ( Mar 12, 2004 )     

      /mse/17654/team_4/AnalysisClassProjectStage2/src/Repman/RepmanConsole.java ( Mar 14, 2004 )

/mse/17654/team_4/AnalysisClassProjectStage2/src/Repman/RepmanData.java ( Mar 15, 2004 )

/mse/17654/team_4/AnalysisClassProjectStage2/src/Repman/RepmanVector.java ( Mar 15, 2004 )

/mse/17654/team_4/AnalysisClassProjectStage2/src/Repman/RepmanRecover.java ( Mar 16, 2004 )     

/mse/17654/team_4/AnalysisClassProjectStage2/src/Repman/RepmanMain.java ( Mar 19, 2004 )     

Replication Manager

SourceCode 2.0

Source

 (19 Mar 2004)

 13. RT-FT with FT baseline  ( Apr 6, 2004)

   

< Failover Spike Graph>

< Contribution Factors for Failover >

 Server Server.java
RepServer.java
LDAPImpl.java
download  ( 8 Apr. 2004)
 Client testClient.java
CorbaObject.java
Locator.jara
download  ( 8 Apr. 2004)

 Replication manager

RepmanConsole.java
RepmanData.java
RepmanFaultInjector.java
RepmanMain.java
RepmanRecover.java

download

 ( 8 Apr. 2004)

< Failover Spike Graph after the strategy applied >

< Reduced Factors for Failover >

<Comparison with before the strategy is applied>

14. Performance  ( Apr 8, 2004)

            We chose load balancing for high performance and have considered two approaches for the way
                    of load distribution. One is CPU based and another is the number of clients based per server. Here each individual request
                    of client can be executed by a thread.

           

           

<From above four graphs, we found out a distinguishable repeating oscillating pattern like above graph.
  The pitch size of spike is increased by 5 as one server is added. From this fact, we can infer that
  this pattern seems to represent a size of thread pool of CORBA server of (JDK 1.4). >

 Server Server.java: Original server
RepServer.java:
Original replica
LDAPImpl.java:
Original servant

DLDAPImpl.java: Dummy servant running without LDAP server (data tier). This is for checking server tier saturation point

download  ( 16 Apr. 2004)
 Client PerformTest.java: Main, Load Distribution logic included

SingleTest.java:Test client for single client

DSingleTest.java:Test client for check saturation point of only server tier without Data tier

clientThread: Worker thread for client

UidReader.java: Text file reader of 1000 different users

uid.txt: 1000 users file

download  ( 16 Apr. 2004)

 Replication manager

RepmanConsole.java
RepmanData.java
RepmanFaultInjector.java
RepmanMain.java
RepmanRecover.java

download

 ( 8 Apr. 2004)



Final presentation