Transcript Matthew Christopher

Iron Architect Challenge
Conference Course Scheduler
By Matthew Christopher
[email protected]
Intentions Of System
► To
provide the best possible service to the
greatest number of participants.
► Provide multiple notification methods of a
room session assignment.
► Provide an adaptive solution for various
tracker, room, size and location
configurations.
System Composition
Register Attendees
& Establish Schedules
Track Attendees
Process Room
Assignments Schedules
Provisioning Client
(Windows Service on Clients Provision
Computers
In session rooms)
Pulls from server using UNC
Provide
Notification
Standard Website
With SQL database
RFID tagged badges
Related back to SQL thru
Web Service
Near Realtime Processor
(Windows Service)
Notification via TV,
Web, Email etc…
Overview System Design
Notification
Service Website
User Tracker
Web Service
User Tracker
Data Access Layer
Notifications
Business Layer
Notifications
Data Access Layer
Schedule
Processor
Distribution Services
(SMTP, RSS, …)
Registration &
Scheduler
Website
SQL
Database
Registration &
Scheduler
Business Layer
Provisioning
Web Service
Notification
Notification
Provisioning
Service
Website
Service
Website
Client
Mapped Drive
Registration &
Scheduler
Data Access Layer
Provisioning
Data Access Layer
Image File Server
Alternate Overview System Design
Using BizTalk Hub
User Tracker
Web Service
RFID Scanners
User Tracker
Data Access Layer
Notifications
Business Layer
Notification
Service Website
Distribution
BizTalk Hub
Services
Registration &
Scheduler
Website
Notification
Notification
Service
Provisioning
Website
Service Website
Client
Schedule
Processor
Registration &
Scheduler
Business Layer
(SMTP, RSS, …)
Notifications
Data Access Layer
SQL
Database
Registration &
Scheduler
Data Access Layer
Provisioning
Web Service
Mapped Drive
Image File Server
Provisioning
Data Access Layer
User Tracker System Design
RFID Reader
RFID Reader
RFID Reader
RFID Reader
User Tracker
Web Service
User Tracker
Data Access Layer
SQL
Database
•The user tracker is based on RFID tags to be carried around by course attendees.
•Each reader records when a user enters their service range and provides user and location
information to the user tracker web service.
•The user tracker web service updates the user current location using the user tracker data
access layer.
•The current user location will be used when processing schedules with the schedule
processing service.
•When installed the relative distances from the RFID readers to the various rooms are
recorded. As well node to node distances are recorded. This will allows detailed control over
traffic flow. This will be discussed in greater detail later.
•The hosting options for this segment can be across one or many servers. As with any well
designed system the connectivity between the components allows for multiple deployment
configurations and hence scalability of the solution.
Notifications System Design
Notifications
Website / Web Part
Notifications
Cable Display
Provider
Notifications
Business Layer
Notifications
Data Access Layer
SQL
Database
Distribution Services
(SMTP, RSS, …)
•The notification system consists of a Notifications website. This is a simple ASPX application
that is updated every minute using JavaScript technology.
•To extend the application for various venues a PC with video output output capability can be
targeted at the notifications website. The output from this can then be amplified and sent to
displays through conference centers supporting coaxial output.
•The website can also be built in the form of a Web Part, or SQL report, allowing it to be
included on SharePoint websites. Again this would be further determined as a result of a
more detailed requirements gathering with the client.
•Users may also wish to receive an e-mail or message feed. This will be sent via the
distribution services component. The notification business layer will call this component each
time the status changes from the status that existed on the previous request.
•The courses shown would include those courses currently in progress, and those scheduled
to start within a configurable time range.
Registration & Scheduler System Design
Distribution Services
(SMTP, RSS, …)
Registration &
Scheduler
Business Layer
Registration &
Scheduler
Data Access Layer
SQL
Database
Registration &
Scheduler
Website
•The Registration and Schedule entry system follows a pattern similar to that of a traditional
website.
•This component while not part of the Iron Architect competition is shown as it is the primary
source for user and schedule information entry into the SQL database.
•Included in the registration process is the ID value of the RFID tag and the desired course
load.
Provisioning System Design
Provisioning
Web Service
Notification
Notification
Provisioning
Service
Website
Service
Website
Client
Mapped Drive
Provisioning
Data Access Layer
SQL
Database
Image File Server
•Due to the high data volume associated with the transfer of the virtual PC images it has
been designed based on a pull configuration over a mapped drive.
•The provisioning client (windows service) runs on the client PC’s and polls the provisioning
web service for updates for course material. It contains a thread that checks every few
minutes for an upcoming course. If no course is found the thread sleeps for a configurable
period.
•If a course has been scheduled as upcoming for the provisioning client any files (names and
locations) are returned.
•A mapped drive at the resulting location is then established and the file is dropped to the
destination on the client PC. Due to the size of the VPC files it may be desirable to have both
high bandwidth or multiple image file servers. As the file locations are configurable it is
possible to have multiple image file servers and or multiple independent networks. Again this
solution has been designed with scalability in mind.
Schedule Processor System Design
Schedule
Processor
SQL
Database
•The Schedule processor is the root of the Conference Course Scheduler.
•This Scheduler processor is a windows service that initially will run on a process
server. While the calculations should be relatively low and therefore simple to run
on one PC it would be possible to distribute the calculations across multiple servers
if required. On the following pages the process for Scheduling rooms will be
discussed in greater detail.
•Not all courses are recorded for active scheduling. Some things like lunch, or
expo hall etc… are not room scheduled and are therefore excluded from the
processing.
•Due to time considerations only a written sequence diagram will be possible.
Failure And Error Management
►
►
►
►
It is possible that the system may fail or not be able to process the
schedule. It a time cutoff point is reached and the room is not
booked. The room will be automatically assigned based on a
preconfigured database value. This would be configured as an SQL
job.
All system will write to the event log using EIF, from which MOM will
be able to monitor and inform the correct individuals of any failure.
Redundancy is achieved by configuring the infrastructure of the system
in the format of web farms, and clusters depending on what they are
hosting.
As well, while not required it may be useful to take advantage of
BizTalk to manage things like SMTP and transaction management.
Schedule Processor Sequence
1.
2.
3.
The system pulls a count of the number of registered users, %
unregistered users expected & course information for upcoming
courses in the period.
The system will then take each resulting adjustment percentage &
multiply it by the number of registered users, add it to the number
of registered users to get the expected user counts by course. As
not all users go to the course they register in, this lets the
organizers adapt based on expected overages.
The list of results are then sorted by expected course counts with
largest first. This will be the order that courses are booked into
rooms to serve the maximum number of people to the best effect.
Schedule Processor Sequence
4.
5.
6.
7.
The system then checks against the database to determine the
average distance for all users to each node location on a course by
course basis. The node distances from other reader nodes are
stored in the database configuration.
When configuring node distances, the values can be adjusted to
perform such functions as attempting to keep people on one floor or
on one side of the building.
The result from the previous query will return by priority the node
locations that represent the greatest node location per user.
The closest room, currently unoccupied, meeting the expected space
requirement is then booked. A value is logged in the database to
initiate the PC provisioning on the next check by the client.
Sample Entities Diagram