Mission Critical Application Architecture and Flash

1
Mission Critical Application Architecture and
Flash
August MDCFUG
Chafic Kazoun, Founder and CTO Atellis
http//www.atellis.com Weblog
http//www.rewindlife.com
2
About myself

• Chafic Kazoun
• Founder and CTO
• chafic_at_rewindlife.com
• Atellis (http//www.atellis.com)
• Blog (http//www.rewindlife.com)

3
Outline

• Overview of Mission-Critical Applications
• Why Flash, am I crazy?
• Introduction to Clinical Skills (Mission Critical
  Product)
• Quick Demo of Clinical Skills Exam System
• Problems we needed to solve
• Introduction to a state based architecture
• When to use a state based architecture
• Brief Back-end implementation overview
• Flash state loader framework overview
• What happens in real-time
• Benefits

4
What are Mission-Critical Applications
Definition Any application that is critical to
the proper running of a business. If this
application fails for any length of time you may
be out of business. For example, an order-entry
system may be considered mission critical if your
business relies on taking lots of orders. You
don't want your mission critical apps running on
junky hardware ... or software for that matter.
5
Why Flash, am I crazy?

• Chernobyl Story
• Ease of use, minimal training can reduce human
  error.
• Flash allows us to build custom UIs easily
• Flash isnt the only thing needed, the back-end
  has to be well thought out too

6
Introduction to the Clinical Skills System

• A complete automated system for administering
  Clinical Skills Exam at University Medical
  Schools
• Requires lots of hardware integration/automation
• Needs to be easy to use
• Can never go down, exams are crucial for medical
  schools and accuracy/reliability is not mandatory
  

7
(No Transcript)
8
Problems we needed to solve

• Flexible system when we want to change the exam
  flow/interface decencies
• Scalability, old system ran at 80 cpu usage
• Reliability, recovering from failures needs to be
  seamless/automatic or simple steps
• Reduce number of personnel required to run the
  exam
• System needs to require minimal training
• Remote log-in patients
• Simple interface for running exams, not
  cluttered, no overload of data
• Lots of checks behind the scene

9
Demo of Clinical Skills Exam System
10
Introduction to a state-based Architecture

• My Definition An architecture where all
  interface data is simplified into states, and all
  states are represented in the database

11
When to use a state based architecture

• Keeping track of states is core to the
  application
• Many interfaces will have a set of states that
  serve a similar purpose, allowing you to simplify
  the interface data

12
A visual of exam states
13
What does state data contain, at least in this
implementation

• Room setup information (case/project/etc)
• Different users that are logged in
• Time
• Recording status/requirement
• Status of the room and each interface
• Session login data, for re-authentication
• Other misc data needed
• Streamline the amount of state data that drives
  the system

14
What happens in real-time Single Interface
15
What happens in real-time Multiple Interfaces
16
What Flash needs to do

• Ability to render states that the back-end asks
  it to
• Maintain a connection with FlashCom to receive
  updates
• Load/Unload states
• Quickly add states
• Be very flexible
• The hardest part in building such applications
  isnt the implementation but the architecture

17
The Flash state loader framework diagram -
simplified
18
Brief Back-end implementation overview

• All available states live in the database and are
  supported by Flash
• All flow information is in the database
• Application server will process requests from
  Flash and make sure they are saved in the
  database
• Whenever states change, some states require extra
  work like talking to hardware/automation. This
  allows you to flag certain states to be recorded
  for example

19
Benefits

• Ability to pick up where you left off
• Restart an interface/computer
• Switch out machines
• Remotely log-in users
• Remotely control interfaces
• Completely flexible flows
• Building states is very easy/quick
• Very stable/reliable
• Very scalable
• Low maintenance, at least for Flash.

20
Things to watch out for

• Maintaining a reliable network connection,
  auto-reconnect, keep alive
• Dealing with different network setups/blocked
  ports/firewalls
• Flash needs to be pretty dumb
• The Back-end needs to be very stable
• Make sure setup is simple
• Make recovery in simple, no way for you to work
  around external problems (hardware/network
  failures)

21
Some additional fall-back plans

• Clustering the database Since the database in
  this scenario is the most important, clustering
  the database will add an extra level of
  redundancy
• Application Server Make sure to design the
  application server in a way that would allow you
  to cluster it too, depending on what application
  server technology it may be easy, or it may take
  a lot of work
• FlashCom FlashCom doesnt support clustering,
  currently working on a custom clustering solution
  but the ability to easily change servers that the
  client uses allows you to always have a backup
  server around

22
Were Hiring

• Were Hiring!

23

• Chafic Kazoun chafic_at_rewindlife.com
• Blog http//www.rewindlife.com
• http//www.atellis.com
• http//www.blinemedical.com
• Feel free to contact me for any details