ATROPOS

Comp 415 ProjectIn partnership with JPMorganChase

INTRODUCTORY REMARKS COMP 415 Class:

Brad Chelsea Dave Felipe Hubert Matt Sohum

Dr. Wong Jacy Grannis

A WORD FROM OUR SPONSORS...

Jacy Grannis has been our customer contact within JPMorganChase. He is a Rice Computer Science graduate and works in JPMorgan’s Houston office.

COMP 415—SUMMARY Software engineering Real customer, real experience Team environment Communication Organization

COMP 415—THE BENEFITS Team programming experience is sought by employers

and not often found in undergraduates Saves on-the-job learning time Industry exposure

COMP 415—THE SEQUENCE COMP 410 COMP 415 Teaching assistant for both courses Need more courses

ATROPOS

…semester in review

ATROPOS—SUCCESS Correlation Network View Single Edge View Remote communication

ATROPOS—MISTAKES Teams change Individuals change Team structure Small team Proxy pattern Integration

SYSTEM REQUIREMENTS…an Atropos primer

SYSTEM REQUIREMENTS—CORRELATION Track messages as they travel between servers Different systems have different message formats

Messages have no fixed unique ID Servers may split and merge messages

SYSTEM REQUIREMENTS—SCALABILITY System must handle thousands of messages per second Components may run on separate machines Concurrency

Asynchronous communications

SYSTEM REQUIREMENTS—RECOVERABILITY Failure of one component should not bring the system

down Failure detection Component restart Restore component state Replay dropped messages

SYSTEM DESIGN…the view from the top

•Distributed system

•Service-oriented architecture (SOA)

•Component registration

ATROPOS SYSTEM DESIGN—UNREGISTERED

•Distributed system

•Service-oriented architecture (SOA)

•Component registration

ATROPOS SYSTEM DESIGN—REGISTERED

DESIGN—ABSTRACTION AND THE PROXY PATTERN

Allows flexible system configuration Beneficial for testing purposes and agile development Unbiased by transfer protocol

DESIGN—DYNAMIC CORRELATION Concepts of finding matches from message organization

are logically distinct Decouple algorithm from data Correlation engines organize messages and use

strategies to fine matches Changing strategies at runtime enables intelligent load

balancing and independence from JPM system configuration

ATROPOS DEMO…which will totally work

START CONTROLLER AND ROUTER Initialize the controller

Service that manages the system Router registers with controller

START CORRELATION ENGINE, DATA CLIENT Correlation Engines and Data Clients run in their own JVMs On startup, they register with the controller Controller configures them to connect them into the system

STARTING VIEW SYSTEM View Provider View Client

CONNECT AND START CLIENT View Client connects to system Requests data

CHANGING SOURCES AND EDGES Utilize IAdmin API to add sources Dynamically add and remove edges Check system status after updates

SINGLE EDGE LATENCY VIEW Access

Dialog Clicking edge in Dashboard View

Display Time-chunk average of latency Scalable to different time periods

Static or updatable

CUSTOM LATENCY VIEW See correlation during a specific time window

UNCORRELATED MESSAGES Messages change, machine connections change, parts of

the topography may disappear completely Messages will stop correlating View uncorrelated messages over a period of time Updates live (currently every 30 secs)

DISCONNECT VIEW CLIENT Disconnect a view client currently registered View client is unregistered

Future updates are no longer sent

REMOTE COMMUNICATION…bridging gaps

REMOTE COMMUNICATION No guarantee that components are on the same

machine Need a way to communicate between multiple

components Solution must be

Scalable Flexible Pluggable

MULE—BENEFITS Provides a scalable package solution Open source Provides a flexible framework that can adapt to any

architecture Can tie into many messaging protocols

MULE—HARDSHIPS Little support and documentation Remote method invocation can cause problems Needs to be scaled to work effectively

FUNCTIONAL COMMUNICATION Proxy pattern connects components Controller as an object on the Mule server Mule support behind remote calls abstracted out

DATA CLIENT…the beginning of it all

DATA CLIENT—GOALS Vehicle for getting messages into the system Robust Abstract Recoverable Extensible

DATA CLIENT—MESSAGE SOURCES Entry point for messages Accepts messages with a simple API

accept(message)... too easy? Next step: router

DATA CLIENT—ABSTRACT Messages can come from anywhere

Log parsers Applications producing the messages Manual API calls

Abstracting out information about the source is crucial for interoperability

DATA CLIENT—RECOVERABILITY Router dies...

What happens to messages that have been sent through the Data Client but are dropped?

Take a lesson from Tivo! Store information about messages that have been seen and

replay! Controller detects failure in the system

Can ynchronize all the modules in the system by replaying the Data Client

DATA CLIENT—EXTENSIBILITY Multiple sources can send information to one data client

Require that incoming messages are be tagged with their source ID

Data Clients can send to other Data Clients Available for common special processing that can be added

at run time Added and removed via registration at run time with the

Controller

ROUTER

…the grunt work

ROUTER—ROLE Data Clients are only aware of Router

All messages simply forwarded Router responsible for mapping Data Clients to

Correlation Engines Data Client to Correlation Engine mapping not 1:1

One-to-many relationship

ROUTER—EXTENSIBILITY Routers can make use of the composite pattern Updated dynamically at runtime by the Controller Whenever Data Clients or Correlation Engines register

(or unregister), the router must reflect those changes

CORRELATION ENGINE…the workhorse

CORRELATION ENGINE—ROLE Organizes messages received Applies correct strategies between various sources, as

determined by the system’s IAdmin Writes correlation information to a memory store Keeps a store of what messages have been received for

replay purposes

CORRELATION ENGINE—DESIGN CONCERNS Configurability

Should handle addition of sources and new rules at runtime Concurrency

Thread safety Use of concurrency to take advantage of multi-cores

CORRELATION ENGINE—IMPLEMENTATION DETAILS Makes messages appear to have been received in order;

facilitates strategy implementation Configurable correlation strategies

Handle rules for correlation Insulated from issues related to system configuration, message order, etc.

USER INTERFACE…the pretty side

VIEW CLIENT—TECHNOLOGIES Eclipse RCP Application Java Universal Network/Graph (JUNG) framework JFreeChart framework

ECLIPSE RCP APPLICATION—POSITIVES Portability Integration with current JPMorgan systems Faster development on Eclipse IDE Powerful framework simplifies component connections

ECLIPSE RCP APPLICATION—NEGATIVES SWT less popular than AWT Fewer resources for help Steep learning curve

VIEW CLIENT—JUNG FRAMEWORK Ability to graph nodes based on set of vertices and

edges Robust decorator-based design for great customization Interactive display with the graph

VIEW CLIENT—JFREECHART FRAMEWORK SWT-native chart creation package Wide variety of charts supported by default Interactive graph display Intuitive package to work with as a developer

VIEW PROVIDER Serves data as requested by many concurrent view

clients Asynchronous "pull" data delivery system Designed to be able to live on a different server than the

view client Ability to handle several different types of data requests Design allows several View Providers to be active, and

for clients to connect to specific ones

VIEW PROVIDER—NETWORK TOPOLOGY Provides the edges and vertices that comprise the

topology Pulls data from the PostgreSql datastore and converts to

viewable form

VIEW PROVIDER—SINGLE EDGE LATENCY Provides time series of latencies between two vertices Parameterization of factors such as time range

VIEW PROVIDER—UNCORRELATED MESSAGES Provides list of messages that have not been correlated

by the system Parameterization of time range allows specific messages

to be identified

VIEW PROVIDER—SINGLE MESSAGE Provides data about the computed correlated paths of

specified messages Includes information about the latency at each vertex in

a given path

THANK YOU FOR COMING!…special thank you to Dr. Wong, Jacy Grannis, and JPMorganChase for making this semester possible!