Berkeley’s Next Generation Webcast/Podcast System
- Administrative application
- Enterprise Integration
- AuthN, AuthZ
- Business rules
- Monitoring Component
- Participation Management/Course Set Up Component
- Lecture and Event Component
- Scheduler
- Starts and stops jobs for the media capture engine
- Reports media capture job status to the admin app
- Tasker
- Controls the media processing engine
- Reports media processing job status to the admin app
- Media capture engine
- Starts and stops media capture devices
- Transfers media to a central location
- Media processing engine
- Encodes and transcodes media
- Trims media
- Brands media
- Publishes media to delivery channels
Subsystem implementation
For the Summer 2008 UC Berkeley pilot, the subsystems are implemented with the following technologies:
- The admin application is a Java web application. See the “Administrative application internals” section below.
- The scheduler is a ruby script
- The tasker is a ruby script
- The media capture engine is implemented via Apple’s Podcast Producer
- The media processing engine is implemented via Apple’s Podcast Producer
Isolation of Podcast Producer
Although Berkeley’s next generation webcast/podcast system uses Apple’s Podcast Producer, the design of the system ensures that its use remains an implementation detail of the media capture and processing layers. Podcast Producer provides a workflow engine, for example, that will be *essentially unused by Berkeley’s next generation webcast/podcast system. Rather than delegate workflow functionality to Podcast Producer, Berkeley’s next generation webcast/podcast system manages the media capture and processing workflows in the WebcastMessagingService (details below), thus allowing for cleaner separation of concerns and easier replacement.
* I write “essentially” because it is not possible to use the product while completely bypassing the workflow engine. We therefore define each Podcast Producer workflow as a single “atomic” task which are pieced together into workflows defined and executed by Berkeley’s next generation webcast/podcast system.
Communication between subsystems
The admin application provides information to the scheduler and tasker via the iCal standard.
Capture and processing job messages are returned to the admin app via HTTP REST.
Administrative application internals
The administrative application itself is a thin user interface atop a set of services that manage the life cycle of a media file. The services maintain and query the database of courses and events to be captured, the media files produced by those capture sessions, and the distribution channels to use in publishing the captured and encoded media. As of December 2007, these services include:
- WebcastService
- Manages the Berkeley’s next generation webcast/podcast system domain model
- Produces the iCal streams for consumption by the scheduler and tasker subsystems
- WebcastMessagingService
- Receives messages from the scheduler and tasker subsystems
- Updates the Berkeley’s next generation webcast/podcast system domain model, creating new tasks as needed
- All media processing workflows are defined here via pluggable handlers. Workflows are executed via communication with the tasker.
The following services sit below the WebcastService and WebcastMessagingService layer, since these define non-domain or enterprise services.
- CourseManagementService (a Sakai API with no dependencies on the rest of Sakai)
- Provides academic session, course, scheduling, and instructor assignments
- FrameworkServiceFacade
- A “catch all” facade for various enterprise services needed by the internal services and the application UI. These may be split into separate APIs if the single facade grows unwieldy.
- Includes authentication, user directory lookups, authorization checks, and localization preferences.
- This has already been implemented via the Sakai APIs, and can easily be implemented using other frameworks. Implementations against Shibboleth and LDAP, for instance, should be trivial.
Anticipated areas of configurability
Berkeley’s next generation webcast/podcast system has a flexible capture capability domain object that models any kind of capture capability. The default configuration includes audio, video, and screen capture, but these could be extended to include different kinds of video (HD vs. DV resolution), audio (stereo vs. mono), or a future media capture technology not currently available. When podcasting became popular a few years ago, UC Berkeley learned the hard way that new kinds of media capture can emerge, and the capture and delivery system must be able to adapt to these new kinds of capture. Our early video-only model did not accommodate new media capture types, so our applications and database schema suffered some ugly mutilation to adapt to this new kind of media. Berkeley’s next generation webcast/podcast system is designed to accommodate new kinds of capture, making the system configurable for any combination of media capture types deployed on other campuses.
Media distribution channels in Berkeley’s next generation webcast/podcast system are also flexible and configurable. The default configuration includes channels for iTunesU, YouTube, and our local webcast.berkeley.edu channel. We are also considering adding a channel for bSpace, our local Sakai instance. Adding distribution channels for other LMS’s should be a straightforward development task.
The workflow engine in Berkeley’s next generation webcast/podcast system is also highly configurable. When a media capture or media processing job is handled (meaning that the job completed, or that it experienced a failure) by the scheduler or tasker, the administrative application is notified that the job has been handled. Depending on the initial state of the job and the kind of notification passed to the administrative application, the workflow engine can create new jobs, cancel or restart existing jobs, or notify interested parties that the job has been handled. The chain of actions taken by the workflow engine is infinitely configurable. The current workflow engine is implemented as a state machine, but could be swapped for more full featured workflow engine to accommodate configuration via BPEL or another standard workflow description language.
Compromises of Configurability and SOA
Although the WebcastService is an abstract swappable interface, the current implementation relies on having all course information, including instructors, locations, and meeting times, in a single database rather than joining local data with course data provided via a service. This deviation from an otherwise service oriented architecture is a compromise that stems from a lack of messaging from our campus SIS. During our initial design work, we tried delegating all course-related queries to the CourseManagementService rather than copying this information into the Berkeley’s next generation webcast/podcast system’s database tables. Although a normalized, service-oriented approach to querying course data made theoretical sense, it turned out to be problematic due to the difficulties our campus’ “pull” model imposed on applying business rules on course data changes.
For example, we have a business rule at UC Berkeley that states that a course should no longer be captured if a new instructor is added to a course and that instructor has not yet submitted an electronic approval for capturing this course. This situation could be handled by implementing a messaging system (such as JMS) to alert the system to the “new instructor” event, but since we have no such messaging infrastructure at UCB and implementing one is out of scope for the Berkeley’s next generation webcast/podcast system development project, using SOA for course data was not an option. The most efficient means we had to determine what data has changed was to keep a local copy of the data, and periodically compare it to the data defined in the SIS.
Another compromise we made relates to the configurability of business rules. One example from UC Berkeley deals with the requirement that a department or organization pay for video capture, but not for audio capture. This rule affects both the service implementation (don’t include course X in the schedule of lectures to be captured, since it hasn’t been paid for) and the user interface (don’t display a checkbox next to course Y, since it does not meet in a video enabled location). We suspect that other institutions will have different rules regarding payment, but we chose to ignore this obvious opportunity for configurability in order to speed delivery of our pilot application.
Authorization features have also been simplified to speed development. Our initial authZ requirements call for only three roles: Course Manager, Special Event Manager, and Super User. These are very course-grained; the Course Manager, for instance, can manage all courses, and there is no means to limit course administration to a subset of courses. We realize that this simplified scheme will be inadequate for many institutions, including our own, but it will meet our requirements for the first phase of our deployment.
