1 / 19

Iron Architect Competition

Iron Architect Competition. Saravana Kumar Digital Deposit Ltd saravana.kumar@digitaldeposit.co.uk. Disaster Recovery Strategy. Session timetable will be produced exactly how it is produced now with Time Slot Breakout Sessions detail , and Room number.

juliette-bernard
Télécharger la présentation

Iron Architect Competition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Iron Architect Competition Saravana Kumar Digital Deposit Ltd saravana.kumar@digitaldeposit.co.uk

  2. Disaster Recovery Strategy • Session timetable will be produced exactly how it is produced now with • Time Slot • Breakout Sessions detail , and • Room number. In the event of system failure, the above mentioned timetable will be published to the attendees through different channels 30 minutes before the session start time.

  3. Registration Process (via msteched.com) • Attendee privacy is top priority • Attendees can opt to enroll themselves for the system to track their presence. • If enrolled, different notification options are given in the later stage • E-Mail • SMS • MSN Alert • If not enrolled, attendees have the following options to get notified • From TechEd website • From Television (Similar to Airport/Train station gate notification) • Can download a P2P client and log in and out of a Peer to Peer Mesh anytime (where information will be broadcasted regularly). • Attendees enter their session preference in “Session Scheduler” before and after registration and any time during the event.

  4. Infrastructure • RFID (Radio Frequency Identification) chip will be installed on all the attendee’s batch. • RFID Receivers will be installed throughout the convention centre, similar to wireless routers now. • RFID Receivers will constantly monitor and record the attendee presence in the RFID database.

  5. Boston Convention Centre Virtual Floor plan Diagram and zone separation. Building is split into zones. In our scenario we have 10 zones across 4 floor.

  6. Architecture

  7. How the system works? • Event Administrators (EA) log into the Room Allocator web site. • EA’s kick of the process, which gathers information from the RFID database ( 5 minutes time window) and produce the corresponding session messages as shown in the below figure (around 20/time slot) and inserts them into the Room Allocator database. Example as shown below

  8. How the system works? ….cont • BizTalk server SQL Adapters are configured to listen for the new messages. • The new ”Session” messages will be picked up by BizTalk and an Orchestration will kick off. • Orchestration will be able to make a decision from the “Session” message in which zone it requires a room. Example: From the previous slide it will decide to pick a room from zone 1. Because for that particular session • Registered attendees = 10 • Attendees in Zone 1 = 7 • A call will be made to “Room Allocation Web Service (RAWS)” asking for a room with • No of Attendees, and • In a Zone( or zones) • If a room is found, then RAWS will book it. • If room in not available with the given criteria, then the “Session” message will be send to “Zone Consolidator Web Service (ZCWS)”, which consolidates the zones in a clever way and returns a new message.

  9. How the system works? …cont Zones Consolidation “Session” Message Consolidation

  10. How the system works? …cont • Zones consolidation service can apply clever algorithm to manipulate the best possible zone consolidation and update the “Session” message accordingly. • The above process will be repeated until the maximum number of iteration rule is reached (set in the BizTalk rules engine by event Administrators). This process can safely be used to allocate roughly 60% - 70% of the rooms. • Event Administrators will then refresh the Room Allocator Web site , which will display the list of sessions for the particular timeslot with corresponding room booking. • They will have the chance to • Allocate rooms for unallocated sessions. • Modify (Overwrite) the allocations made by Orchestration (the one shown above). • Once all the allocations are done. From the web site EA’s will be able to kick the notification service to send notifications in variety of channels (SMS, email, web site , P2P, TV etc) in varying formats.

  11. If required the whole schedule can be done via this manual tool, rather than relying on BizTalk Orchestration (If necessary)

  12. Session Message • Session will have zones and zones will have attendees detail (whoever opted to reveal their presence). • Session:RegisteredAttendees: Total number of attendees registered for the session using session scheduler. • Zone:TotalNoOfAttendees: Total number of attendees detected (through RFID) in the zone.

  13. Room Allocation Web Service (RAWS) • Responsible for maintaining inventory of the rooms within the zone or multiple zones.. • Rooms may be removed from the zone for various reasons like AV failure, Lighting failure etc. • RAWS should be capable of handling this situations and more.

  14. Zone Consolidator Web Service (ZCWS) • Takes a “Session” message, consolidates the zones in a clever way, updates the “Session” message and sends it back. (Example: shown in earlier slides.) • Example: In the picture we can see 3 types of consolidation. • Orange and Green • Orange and light green • Orange, Green and Blue. ZCWS can have multiple consolidation logic like the one shown in the picture.

  15. NotificationService • Responsible for sending the notification via different channels • SMS • Email • Television • Update TechEd.com DB • P2P mesh update. • Formatting the message according to the correct channel. • Sending message to correct set of people (privacy)

  16. Virtualization Environment • All the virtual pc images are loaded in this virtualization environment. • Speakers will use Virtual Server 2005 R2 to access this VHD’s from the network. • A copy will also be transferred to the workstation in the corresponding room as backup. • Speaker will also carry a copy of the VHD image in their laptop as additional disaster recovery operation.

  17. Room Allocator Database • Contains tables, stored procedures and data required to maintain • Zone information • Room inventory • All other custom database requirements for the project

  18. Summary • Due to time constraint some of the following stuff are incomplete or not explained. • Deployment Architecture • Security Architecture • Scalability Architecture. • Reliability (Database cluster ,Load balancing etc) • The design is more at conceptual level and serious drill down into individual areas is required.

More Related