1 / 26

MIT iCampus iLabs Software Architecture Workshop

MIT iCampus iLabs Software Architecture Workshop. June 13 - 15, 2006. iLab Batched Experiment Architecture: Client and Lab Server Design. iLab Training Course P. Bailey & J. Hardison June 13 – 15, 2006. Campus network. Internet. Lab Server. Client. Service Broker.

Faraday
Download Presentation

MIT iCampus iLabs Software Architecture Workshop

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. MIT iCampus iLabsSoftware Architecture Workshop June 13 - 15, 2006

  2. iLab Batched Experiment Architecture:Client and Lab Server Design iLab Training Course P. Bailey & J. Hardison June 13 – 15, 2006

  3. Campus network Internet Lab Server Client Service Broker The Big Picture:Batched labs in the iLab Shared Architecture • Service Broker provides generic services, deployment mechanism for the client. • Lab Server and Client contain lab-specific code. • All communications pass through Service Broker.

  4. Lab Developer Tasks • Design Lab Client • Bound by Lab-specific UI requirements, iLab API • Design Lab Server • Bound by lab instrumentation, desired functionality, iLab API • Design Client-Server communication framework

  5. Public Internet Arbitrary Service Broker Lab Server Client Lab Client–Server Communication • Messages passed between Client and Lab Server communicate key lab information. • Lab Hardware Configuration/Status • Experiment Parameters & Results • This information is necessarily lab-specific.

  6. ? Lab Client–Server Communication • All Lab Client-Server Messages must be passed through Service Broker. • Generic mechanism. • XML an ideal technology for this application. Arbitrary Lab Clients Arbitrary Lab Servers Service Broker

  7. Lab Server Design: Basic Requirements • Provide access to lab hardware. • Implement the iLab Lab Server API • Define & utilize format for lab-specific communication with the Client. • Provide any other functionality necessary for lab operation Note:iLab Architecture APIs are platform-neutral. Lab Server technology driven by lab resources, hardware requirements.

  8. Lab Client Design: Basic Requirements • Provide and educationally valuable user interface to the lab. • Implement the iLab Client API • Create & Interpret lab-specific communication with Lab Server. Again…iLab Architecture APIs are platform-neutral. Lab developer can select the best technology for their Client.

  9. Development Example:The Microelectronics WebLab • Online microelectronic device characterization lab. • First lab deployed using the iLab Architecture. • Used by students, guests & OCW users worldwide.

  10. The Microelectronics WebLab:Lab Client-Server Communication • Three distinct message types used for lab-specific communication between Client and Lab Server. • Lab Configuration • Experiment Specifications • Experiment Results • XML is used to encode information. • Passed through the Service Broker as generic text.

  11. The Microelectronics WebLab:The Lab Server Lab Server Requirements: • Scalable performance and reliability. • Asynchronous experiment submission and execution • Fault-tolerance • Built-in lab management utilities. • Highly modular, extensible.

  12. The Microelectronics WebLab:The Lab Server Built on Windows using .NET Framework and MS SQL Server.

  13. The Microelectronics WebLab:The Lab Server – Web Server • Responsible for interaction with outside world • Contains libraries responsible for experiment validation & DB interaction • Shared Library used to parse Experiment Specification messages during validation

  14. The Microelectronics WebLab:The Lab Server – Data Storage • SQL database used to store lab data: • Connects Web Server & Execution engine. • Provides data persistence. • Submitted Experiment Specifications queued in DB for execution process. • Complex data interactions are internal.

  15. The Microelectronics WebLab:The Lab Server – Execution Engine • Governs experiment execution. • Retrieves Experiment Specifications from DB queue. • Communicates with lab hardware via low-level custom drivers. • Stand-alone process • Shared Library used to parse Experiment Specification messages for execution

  16. Lab Server Highlights:Experiment Queuing Experiments are processed in an asynchronous manner… • Web Server Layer receives, validates job submissions and adds it to the queue. • Execution Layer de-queues jobs when hardware is available, returns results Removes major performance bottleneck, reduces dependence on any one process

  17. Lab Server Highlights:Experiment Validation All experiments are validated on the server before they are queued: • Jobs are checked for: • Basic Correctness • Compliance with Hardware capabilities • Compliance with Server-imposed rules • Reduces resources spent on incorrectly specified jobs. • Server-based validation ensures uniformity, rapid application of changes

  18. Lab Server Highlights:Lab Management Most Lab Management functions available online: • Used to view system status/logs, edit system configuration. • Interface geared towards common functions • Allows rapid response to events

  19. The Microelectronics WebLab:The Lab Client Client Requirements: • Intuitive interface • Easily deployed on many platforms • Minimal user requirements • Highly modular design • Easily extensible

  20. Meeting Client Design Goals:Portability Java used to develop client. • Ubiquitous as client execution environment • Good cross-platform compatibility • Places few special requirements on end-user • Packages/toolkits provide necessary functionality • Graphical UI, Web Services, XML all within reach • Versatility • Few constraints imposed by technology

  21. Other Client Technology Options • Stand-alone application (.NET, Java, C/C++, etc.) • Versatile • Typically more platform dependent • User must download/install client • HTML/Web Script based client (.NET, Java/JSP, PHP, etc.) • Typically more portable, easy to deploy • Potentially fewer interface options (limited educational value) • Client development packages (LabView) • Rapid deployment, flexible interfaces • Requires client runtime plugin • More methodology than technology, hard to integrate with Batched-Lab Architecture (outlook much better for Interactive labs)

  22. Meeting Client Design Goals:Modularity/Extensibility Client built from three distinct modules: • User Interface Layer • Only presentation code • Main Client Module • Contains core functionality • Server Interface • Translates Core commands to Web Service Calls Many changes can be isolated.

  23. Client Extensibility:The Classical Applet A more nimble client needed for deployment in bandwidth starved areas • Graphical Applet’s intuitiveness comes at the expense of size/end-user requirements • A new UI Layer was needed to meet these needs

  24. Client Extensibility:The Classical Applet • Both clients use the same Core Functionality and Server Interface modules • Classical applet is smaller (94KB vs. 169 KB) and has fewer requirements

  25. Reusability of WebLab Code • Lab Client/Server code is lab-specific • Exception is Client graphing module • However, some parts can be reused with modification • Client/Server – Broker Interfaces, some management tools, Execution queuing, Client/Server infrastructure… • Deployed labs always valuable as working examples

  26. Conclusions • iLab Shared Architecture, Service Broker eases lab development. • Turnkey generic functionality • Well-defined client/server APIs • Lab Client & Server interact over generic transport using lab-specific messages. • Remainder of lab development framed by case specifics. • Previous labs can be leveraged in new development • iLab Development Documentation & WebLab code available at http://icampus.mit.edu/ilabs

More Related