Kamerka WebService

Zdarzyło mi się ostatnio napisać WebService zwracający ramkę z kamerki (typu Webcam, nie IPCam) podłączonej do serwera na żądanie. Dzieło to jest jeszcze niedokończone, nieidealne i przede wszystkim nie przetestowane w warunkach bojowych, ale działa.

Do obsługi kamerki użyłam gotowego COMa pożyczonego z codeproject. Pisanie tego od zera jakoś mnie nie pociągało :)

Aby używać takiej dll'ki należy zarejestrować ją w systemie:
-wrzucić do ../Windows/system32
- wykonac w linii poleceń:
regsrv32 "CamServer.dll"
jakby co exe z regsrv32 też jest w ../Windows/system32.


Teraz można już dodawać sobie referencje do tegoż COMa do projektu (tu uwaga bo w systemie jest też COM nazwany CamServr, należy zwrócić uwagę na literkę "e").
Potem można już pobierać ramkę z kamerki:
CAMSERVERLib.Camera cam = new CAMSERVERLib.CameraClass();

byte[] frame = (byte[])cam.GrabFrame(quality);

Chyba już widać, dlaczego nie chciało mi się tego pisać od zera :P

Sam webservice to już wolna amerykanka, co kto lubi :)
Ja zrezygnowałam z SOAPa, aby pominąć przesyłanie taaakiego xml i przesyłać tylko to o co chodzi - obrazek z kamerki. RESTful wydał się dostatecznie wydajny, WCF byłby lepszy, bo można by przerobić kod na wszystko, no ale docelowy serwer to IIS 6, więc mogłby być problemy.

Co to jest ten REST? W Visual Studio SOAPowe WebService to taki typ projekt, o REST ni widu ni słychu. Okazuje się, że nie taki diabeł straszny, aby stworzyć WebService REST'owy wystaczy napisać klasę implementującą interfejs IHttpHandler, reszta wygląda podobnie jak przy SOAP. Przy czym REST ma jeszcze zasady odnośnie wymogu przetwarzania żadań http typu POST, GET, HEAD, DELETE...
Polecam coś doczytać na ten temat :)

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class WebCamService : IHttpHandler
{

public void ProcessRequest(HttpContext context)
{
...
}

}

Zachowanie ProcessRequest jednoznacznie skojarzyło mi się z JAVA'owym servletem. Bierzemy sobie writer i jedziemy :P

context.Response.OutputStream.Write(frame, 0, frame.Length);

No i niby wszystko pięknie, na rządanie klient dostaje ramkę z kamerki.
Tak oto nasz WebService niby działa. Teraz juz można otworzyć piwko i świętować sukces XD.... Bullshit :P

Po podałączeniu 3 klientów proszących o ramekę co kilka sekund całość się popisowo wykrzaczy :P

Wyjścia są różne - puścić webservice z kamerką z jakąś dozwoloną pulą połączeń, pilnować wątków aby zapobiec konkurencji w dostępie do zasobu, jakim jest nasze urządzonko. Na moje brzmi to trochę na łapu-capu... Epic fail XD

Wyjściem, jakie planuje zrealizować, jest napisanie usługi (jeszcze nie wiem jakiego typu), którą klienci prosiliby o subskrypcję na dostęp do kamerki. Usługa czyta z kamerki ramkę co jakiś minimalny czas i rozsyła ją do klientów z zadaną przez nich intensywnością (np. czyta ramkę co 0,25 s i wysyła co czwartą klientowi, który zapisał się na wysyłanie ramek co sekundę).

Kamerka pozostanie Webservicem, aby cały system można było rozproszyć - jakiś mały serwerek hostuje kamerkę i stoi w porządanym miejscu (może o tym nie wspomniałam, ale cała idea posiadania takiej kamerkowej usługi to monitoring za pomoca webcam'ów), zaś serwer z usuługą multicastową stoi gdzie indziej.

Termin realizacji: po sesji podstawowej :P Oby coś z tego wyszło :)

Dodam jeszcze, że samą realizację kamerka + usługa multicastująca odczyty z niej, można uogólnić na przypadek z użyciem czujnika dowolnego typu zamiast kamerki. No ale to dopiero w kolenej wersji mojego dzieła:P

Note to self: Zapamiętać - znaleźć jakieś cudo do wstawiania sformatowanego kodu źródłowego na bloga