Archive for category Wowza
Future Stack
I have been searching for answers. My goal is to be able to build Streaming/RichMedia internet applications on a truly stable and robust basis, that leverages the best standard tools available to modern software developers.
Having done most development until now with the powerful but “designed by Committee” Java, and the powerful but “engineered by impatient enthusiasts” Red5 streaming server, with powerful but inadequately backed “nearmiss” OpenLaszlo, I have aquired a taste for something I can really believe in and work with.
After reviewing a number of technologies, the technology stack I’m currently aiming for is :
- JQuery -where DHTML is needed, JQuery is excellent
- Flex 3 (+ Air) -the most ubiquitous and mature RIA technology available
- Cairngorm framework/PureMVC
- Wowza/WebORB -not feature rich, but powerful and robust Streaming Media Servers
- Spring + Hibernate
- JSecurity - a security framework which, while not perfect, leaves the right decisions to the implementor and keeps complexity at a minimum
This seems to contain a good blend of efficiency, robustness, and long-term technological/corporate survivability.
PureMVC vs. Cairngorm : ( http://www.websector.de/blog/2007/08/10/another-weborb-for-php-login-sample-using-flex-and-puremvc/ http://www.websector.de/blog/2007/08/08/weborb-for-php-login-example-using-flex-3-and-caingorm-221/)
Integrating JSecurity with Wowza Streaming Media Server – Attempt 1
Whenever a method request comes into the server, JSecurity must be able to work out which Subject (person) the request is for, inorder to calculate if that Subject is authorized to access the method being called.
Typically JSecurity stores the Subject in a ThreadLocal because, typically, a single Thread is used to service a single client session. Whenever a new request comes in, therefore, JSecurity can just whip the Subject back out of the Thread executing the method and it knows who it’s dealing with.
Wowza, however, assigns a seperate Thread for every client interaction from a Thread Pool. This breaks the JSecurity scheme in two ways, as between method requests not only is the Subject unlikely to be available (unless by chance the same Thread is picked from the ThreadPool a second time), but the wrong subject from a previous method call may still be attached throwing the whole thing into chaos.