České vysoké učení technické v Praze Fakulta elektrotechnická
Diplomová práce
Ovládání IP kamery prostřednictvím Cisco IP telefonu Petr Milanov
Vedoucí práce: Ing. Jan Kubr
Studijní program: Elektrotechnika a informatika, strukturovaný Obor: Výpočetní technika (magisterský) Květen 2008
ii
Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
V Mnichově Hradišti, dne 20. května 2008
…………………………………… Petr Milanov
iii
iv
Abstract The aim of this work is to develop an application that will permit Cisco IP phone to control an IP camera. The application will enable the IP phone to choose one IP camera from a list of available IP cameras and it will consequently show the IP camera video stream on the IP phone’s display. Because of constrained capabilities of the IP phone the video stream will be displayed as a sequence of images. Images will be periodically refreshed at the highest possible frequency. Additionally, the application will provide control of the IP camera (pan, tilt and zoom) based on the camera capability. Finally, the solution will be tested in real deployment.
Abstrakt Cílem práce je vytvoření aplikace pro ovládání IP kamery pomocí Cisco IP telefonu. Aplikace umožní prostřednictvím IP telefonu zvolit jednu z více dostupných IP kamer a následně zobrazit její video vysílání na displeji IP telefonu. Vzhledem k omezeným schopnostem IP telefonu bude video vysílání zobrazeno jako sekvence obrázků. Podle možností použitého hardwaru (Cisco IP telefonu) bude tato sekvence obrázků obnovována v maximální možné frekvenci. Aplikace dále umožní ovládání kamery (přiblížení, vzdálení objektu a natáčení objektivu kamery) podle možností použité kamery. Nakonec se řešení otestuje v reálném nasazení.
v
vi
Obsah 1. Úvod .................................................................................................................................................................. 1 2. Prvotní návrh aplikace..................................................................................................................................... 2 Zadání a použitá terminologie ........................................................................................................................... 2 Návrh vypracování ............................................................................................................................................. 2 Komponenty použité pro sestavení systému.................................................................................................. 3 IP kamera .................................................................................................................................................. 3 Cisco IP telefon......................................................................................................................................... 4 Middleware aplikace................................................................................................................................. 4 Základní princip fungování systému a vyvíjené middleware aplikace ..................................................... 5 IP telefon................................................................................................................................................... 6 Vývoj služeb určených pro Cisco IP telefony ............................................................................................... 8 Klíčové komponenty síťové architektury z pohledu vytváření služeb pro IP telefony ............................. 8 Aplikační protokoly či protokoly vyšších vrstev zajišťující chod služeb IP telefonů.................................... 9 3. Grafické formáty ............................................................................................................................................ 13 JPEG (Joint Picture Experts Group) ............................................................................................................... 14 PNG (Portable Network Graphics) .................................................................................................................. 16 Kdy se rozhodnout pro JPEG a kdy pro PNG? ................................................................................................ 18 Motion JPEG.................................................................................................................................................... 19 Detailnější rozbor Motion JPEG vysílání z IP kamery Axis 213 PTZ ........................................................ 20 4. Návrh aplikace CiscoIPPhoneIPCameraService ................................................................................. 24 Jakarta projekt a Apache Tomcat..................................................................................................................... 25 Java Servlet a Java Server Pages..................................................................................................................... 26 Java Beans ....................................................................................................................................................... 28 Konvence Java Beans .................................................................................................................................. 28 Uchovávání informací o registrovaných IP kamerách..................................................................................... 28 JDBC (Java Database Connectivity) ........................................................................................................... 29 JDBC ovladač (driver)................................................................................................................................. 30 JDBC-ODBC a ODBC-JDBC Bridge .................................................................................................... 31 Native-API driver ................................................................................................................................... 31 Network-Protocol Driver (Pure Java Driver for Database Middleware)................................................. 32 Native-Protocol Driver (Direct to Database Pure Java Driver)............................................................... 33 XML soubor pro uchování informací o IP kamerách .................................................................................. 34 Výhody a nevýhody ukládání dat do XML souboru respektive do databáze............................................... 35 Základy práce s databází v Javě................................................................................................................... 35 5. Popis aplikace CiscoIPPhoneIPCameraService................................................................................... 38 Balík ciscoIPPhoneIPCameraService ............................................................................................................ 38 Aplikační kontrolér (třída ApplicationController)...................................................................................... 38 Třída ApplicationException ....................................................................................................................... 40 Balík image a třída ImageResizer ................................................................................................................. 40 Balík io ............................................................................................................................................................. 40 Třída DatabaseHandler ............................................................................................................................. 40 Třída ImageRemover................................................................................................................................. 41 Třída InputOutput ........................................................................................................................................ 41 Třída SAXHandler....................................................................................................................................... 42 Třída XMLParser......................................................................................................................................... 42 Balík ipCamera ................................................................................................................................................ 42 Třída IPCamera .......................................................................................................................................... 42 Třída IPCameraException ......................................................................................................................... 45 Třída IPCameraStopper............................................................................................................................. 46
vii
Balík webAndCiscoIPPhone ........................................................................................................................... 46 Třída (Java Bean) AdministrationBean...................................................................................................... 47 Třída (Java Bean) IPCameraFormBean..................................................................................................... 48 Třída (Servlet) IPCameraService............................................................................................................... 49 Třída (Servlet) IPPhoneServices................................................................................................................ 49 Třída (Servlet) ImageRequestsHandler ....................................................................................................... 49 Třída MyHTTPClient ................................................................................................................................... 51 Třída (Servlet) RegisteredIPCameras ....................................................................................................... 51 Java Server Pages (JSP) .................................................................................................................................. 52 6. Měření ............................................................................................................................................................. 53 7. Závěr................................................................................................................................................................ 56 Použitá literatura a zdroje.................................................................................................................................. 61 Příloha 63 1. Speciální značkovací sekvence používané formátem JPEG ....................................................................... 63 2. Veřejně přístupné IP kamery ...................................................................................................................... 63 Axis 213 PTZ Network Camera (Live view) ............................................................................................... 63 Axis 214 PTZ Network Camera (Live view) ............................................................................................... 64 Sony Network Camera SNC-RZ30 ............................................................................................................. 64 Sony Network Camera SNC-CS10.............................................................................................................. 64 Panasonic Network Camera BL-C10A........................................................................................................ 64 3. Přehled XML objektů podporovaných Cisco IP telefony............................................................................ 65 4. Obsah přiloženého CD ............................................................................................................................... 68
viii
Seznam obrázků Obr. 1
– Zjednodušené schéma systému .............................................................................................................. 3
Obr. 2
– Cisco IP Phone 7975G a bezdrátový Cisco IP Phone 7921G ................................................................ 6
Obr. 3
– Cisco IP Communicator 2.1 (Softphone) ............................................................................................... 7
Obr. 4
– Klíčové komponenty síťové architektury z pohledu vytváření nových služeb pro IP telefony ............. 8
Obr. 5
– Protokoly vyšších vrstev využívané IP telefony při komunikaci ......................................................... 10
Obr. 6
– Stažení firmware a konfigurace a následný přístup ke službám .......................................................... 12
Obr. 7
– XML objekt sloužící pro předání reference na obrázek....................................................................... 12
Obr. 8
– Porovnání kvality obrázků ve formátu JPEG z různou mírou ztrátovosti (kvality Q) ......................... 13
Obr. 9
– Porovnání komprese JPEG/JFIF a JPEG 2000 .................................................................................... 15
Obr. 10 – Jiné porovnání JPEG a JPEG 2000...................................................................................................... 16 Obr. 11 – Původní JPEG komprese a nová vlnková (wavelet) komprese (ukázka wavelet komprese používané formátem LWF vyvinutým firmou Luratech); výsledky jsou poněkud zkreslené, jelikož je výše prezentovaný obrázek uložen ve formátu JPEG) ................................................................................ 16 Obr. 12 – Porovnání JPEG versus PNG při ukládání textu (obrázku s ostrými přechody) .................................. 18 Obr. 13 – Přenos Motion JPEG vysílání (streamu) v rámci HTTP dat mezi aplikací a IP kamerou.................... 20 Obr. 14 – Ukázka výstupu aplikace Wireshark použité pro sledování Motion JPEG vysílání (streamu) ........... 20 Obr. 15 – Analýza HTTP dat – identifikace začátku JPEG obrázku nalezením speciální sekvence 0xFFD8, rovněž je patrný i typ přenášených dat a jejich délka.......................................................................... 21 Obr. 16 – Analýza HTTP dat – identifikace konce JPEG obrázku (0xFFD9) a následného začátku dalšího JPEG obrázku (0xFFD8) zasílaného v rámci Motion JPEG vysílání (streamu)............................................ 21 Obr. 17 – Textová podoba analyzovaných dat – nejprve je prezentována HTTP hlavička, následuje oddělovač individuálního JPEG obrázku v rámci Motion JPEG vysílání (streamu), dále JPEG hlavička (s uvozovací sekvencí 0xFFD8) a vlastní data obrázku .......................................................................... 22 Obr. 18 – Textová podoba analyzovaných dat – na začátku jsou data prvního JPEG obrázku, následuje speciální sekvence označující konec prvního JPEG obrázku (0xFFD9) a koncový oddělovač (nový řádek), poté jsou prezentovány počáteční oddělovače JPEG obrázku, za nimi počáteční uvozovací sekvence (0xFFD8) a vlastní data druhého JPEG obrázku ................................................................................. 22 Obr. 19 – Čtyři počáteční a jeden koncový oddělovač JPEG obrázků používaný IP kamerou Axis 213 PTZ .... 23 Obr. 20 – Znázornění „života“ JSP stránky ......................................................................................................... 26 Obr. 21 – Ukázka „HelloWorld“ servletu (jedná se o výsek zdrojového kódu vygenerovaného vývojovým prostředím NetBeans 6.0).................................................................................................................... 27 Obr. 22 – Výstup „HelloWorld“ servletu zobrazený ve webovém prohlížeči Mozilla Firefox ........................... 27 Obr. 23 – Ukázka metod „getter“ a „setter“ pro (privátní) proměnnou value (typu String) ............................... 28 Obr. 24 – Propojení aplikace s MySQL databází................................................................................................. 29 Obr. 25 – JDBC architektura................................................................................................................................ 30 Obr. 26 – JDBC-ODBC bridge (JDBC driver type 1) ......................................................................................... 31 Obr. 27 – Native-API ovladač (JDBC driver type 2) ........................................................................................... 32 Obr. 28 – Network-Protocol Driver (Pure Java Driver for Database Middleware; JDBC driver type 3) ............ 33 Obr. 29 – Native-Protocol driver (Direct to Database Pure Java Driver; JDBC driver type 4) ........................... 34 Obr. 30 – Struktura XML souboru pro uchování informací o známých IP kamerách (v tomto případě je uvedena pouze jedna kamera, jejíž parametry jsou definované mezi elementy IPCamera) ............................. 34 Obr. 31 – Základy práce s databází v Javě (ukázkový kód 1).............................................................................. 35 Obr. 32 – Základy práce s databází v Javě (ukázkový kód 2).............................................................................. 36 Obr. 33 – Základy práce s databází v Javě (statický inicializer třídy Driver) ...................................................... 36 Obr. 34 – Základy práce s databází v Javě (ukázkový kód 3).............................................................................. 36
ix
Obr. 35 – Ukázkový (neúplný) zdrojový kód v Javě pro spojení s MySQL databází a provedení jednoho základního dotazu................................................................................................................................ 37 Obr. 36 – Konstruktor aplikačního kontroléru (validate je privátní, statická metoda)........................................ 39 Obr. 37 – Metoda getApplicationController (aplikace on-demand/lazy inicializace, proměnná appController je privátní, statická proměnná třídy ApplicationController) .................................................................. 39 Obr. 38 – Konstruktor objektů třídy ImageRemover......................................................................................... 41 Obr. 39 – Konstruktor objektů třídy IPCamera................................................................................................... 43 Obr. 40 – Metoda saveImage objektu třídy IPCamera ..................................................................................... 44 Obr. 41 – Metoda moveRight objektu třídy IPCamera ...................................................................................... 45 Obr. 42 – Hlavní metoda (run) vlákna IPCameraStopper (ipc je privátní proměnná referencující objekt třídy IPCamera) .......................................................................................................................................... 46 Obr. 43 – Ukázka „getter“ a „setter“ metod pro proměnnou username (typu String) ....................................... 47 Obr. 44 – Možná definice vstupního pole pro zadání textu (zde uživatelského jména) v HTML formuláři definovaném v JSP stránce.................................................................................................................. 47 Obr. 45 – Příklad definice (element jsp:useBean) reference na AdministrationBean v JSP stránce a nastavení všech proměnných (element jsp:setProperty), tj. vlastně volání metod „setter“............................... 47 Obr. 46 – Zkrácená verze instanční metody startApplication třídy AdministrationBean ................................. 48 Obr. 47 – Identifikace relace „telefon-kamera“ pomocí HTTP Cookie „camera“.............................................. 50 Obr. 48 – Speciální značkovací sekvence používané formátem JPEG ................................................................ 63
x
1. Úvod První myšlenky o vybudování počítačové sítě se objevily již na počátku šedesátých let dvacátého století v USA. Tehdy, v době studené války, se mělo jednat o síť propojující nejdůležitější vojenské, vládní a akademické počítače, schopnou přežít i jaderný útok. Tyto myšlenky začaly být postupně realizovány na konci šedesátých let. Na podzim roku 1969 byly zprovozněny první čtyři uzly sítě ARPANET (všechny čtyři uzly byly umístěny na amerických univerzitách). V roce 1971 se velikost sítě ARPANET rozrostla na 15 uzlů, v roce 1972 bylo propojeno již 37 počítačů. K prvnímu rozšíření sítě za hranice amerického kontinentu došlo roku 1973, kdy byla připojena University College of London a Royal Radar Establishment. V roce 1974 byla zveřejněna první specifikace protokolů TCP/IP, k nimž se oficiálně přešlo v roce 1983. Období mezi lety 1983 a 1992 přineslo prudký rozvoj Internetu (z přibližně tisíce stanic v roce 1983 se síť rozrostla na více než milion stanic v roce 1992). Na začátku tohoto období se přenosové kapacity páteřních sítí pohybovaly na rychlostech okolo 56 kbit/s, ke konci pak dosahovaly rychlostí kolem 50 Mbit/s. Začátek devadesátých let přinesl první hypertextový dokument, čímž byl položen základ dnes nejpoužívanější služby Internetu. Prudký nárůst obliby WWW se datuje k září 1993, kdy byla uvedena první funkční verze velmi populárního prohlížeče NCSA Mosaic. Vstup komerčních organizací roku 1993 se stal definitivním zlomovým momentem v rozšíření Internetu. Počet uživatelů Internetu každým rokem mnohonásobně rostl, až se Internet stal, prakticky po celém světě, každodenní součástí života. Dnes se nad komunikačními sítěmi založenými na protokolech rodiny TCP/IP provozují nejrůznější služby. Dochází k tzv. konvergenci služeb. Proto již není třeba budovat pro různé typy aplikací či služeb speciální infrastrukturu postavenou na dedikovaných zařízeních. Veškeré služby, ať už je to přenos klasických (počítačových) dat, telefonie či video, lze unifikovat a provozovat nad jednotnou komunikační sítí. Sjednocení stávajících aplikací a služeb dovoluje i následné vytváření služeb nových. Poměrně prudce se rozvíjející oblastí dnešních datových sítí je IP telefonie. Díky přístupu telefonů k IP síti a rozvoji možností samotných zařízení, tedy telefonů jako takových, je pro ně možné vytvářet služby zcela nové, přičemž jejich účel může být téměř libovolný.
1
2. Prvotní návrh aplikace Zadání a použitá terminologie Úkolem této práce je vytvoření aplikace, která dovolí Cisco IP telefonu ovládat IP kameru. Aplikace má umožnit, prostřednictvím Cisco IP telefonu, zvolit jednu z více dostupných IP kamer a následně zobrazit její video vysílání na displeji Cisco IP telefonu. Vzhledem k poněkud omezenějším schopnostem Cisco IP telefonu, myšleno ve srovnání například s klasickým počítačem, bude toto video vysílání zobrazeno jako sekvence periodicky aktualizovaných obrázků. Podle možností konkrétního použitého hardwaru (Cisco IP telefonu) pak bude tato sekvence obrázků obnovována v maximální možné frekvenci. Aplikace má rovněž umožnit ovládání IP kamery (přiblížení, vzdálení objektu a natáčení objektivu kamery), opět dle možností konkrétní použité kamery. Nakonec bude vytvořená aplikace otestována. Z důvodu lepší čitelnosti textu budou termíny Cisco IP telefon, IP telefon a telefon, resp. IP kamera a kamera, používány zaměnitelně. Pokud bude třeba mezi těmito pojmy odlišit, bude tato skutečnost zřejmá z kontextu, nebo na ni bude explicitně upozorněno.
Návrh vypracování Celý systém se bude skládat z několika částí či komponent. První součástí systému bude Cisco IP telefon, druhou IP kamera, třetí bude vlastní vyvíjená aplikace, která bude fungovat jako middleware, dovolující přistoupit IP telefonu ke službám IP kamery a zajišťující potřebnou konverzi komunikačních (ovládacích) zpráv a formátu videa do formy, kterou dokáže Cisco IP telefon prezentovat svému uživateli, tedy do formy zobrazitelné na displeji telefonu. Informace o dostupných kamerách bude třeba uchovávat bez ohledu na běh aplikace, tj. bude třeba je ukládat buď na lokální disk, či do nějaké databáze. Na mezilehlou komunikační síť propojující jednotlivé komponenty můžeme rovněž nahlížet jakožto na další (poslední) část celého systému. Vzhledem k použití IP telefonu, resp. IP kamery, bude tato síť zajišťovat přenos právě IP datagramů, tj. zpráv (datových jednotek) protokolu IP (Internet Protocol).
2
Obr. 1 – Zjednodušené schéma systému
Komponenty použité pro sestavení systému IP kamera Nejlepší volbou pro potřeby vyvíjené aplikace bude použití takové IP kamery, která podporuje ovládání přes webové rozhraní (prostřednictvím HTTP protokolu) a poskytuje video výstup (video stream) ve formátu Motion JPEG, zkráceně MJPEG. Komunikace s kamerou tedy bude probíhat využitím HTTP protokolu, pomocí něhož lze kameře předat výzvu (příkaz) k provedení nějaké akce. Tou může být zahájení, resp. ukončení snímání okolního prostředí a s tím spojené odesílání video vysílání k jeho spotřebiteli (požadateli či konzumentovi), další akcí je například přiblížení, resp. vzdálení, snímaného objektu nebo natáčení objektivu kamery. Kamera poté, dle svých možností, danou akci provede, tedy například pootočí objektivem o daný, výrobcem definovaný, úhel. Video vysílání se bude sestávat ze sekvence po sobě jdoucích JPEG obrázků oddělených nějakým separátorem, tedy Motion JPEG (MJPEG). Jinou možností formátu video vysílání by mohl být MPEG (ať už MPEG-2 či MPEG-4). Ovšem pro účely vyvíjené aplikace je spíše vhodnější vysílání ve formátu MJPEG, tedy ona sekvence obrázků, jelikož by se na sekvenci obrázků stejně muselo konvertovat i případné MPEG vysílání (dáno současnými možnostmi Cisco IP telefonů). Konkrétně se jako nejlepší řešení jeví použití kamer od společnosti Axis. Tyto kamery totiž nabízí poměrně dobré možnosti integrace s vyvíjenou aplikací. Dále je několik IP kamer od tohoto výrobce veřejně přístupných na Internetu, a tak se dají zdarma využít jako komponenty systému, což je vzhledem k jejich ceně velice příjemné. Příkladem kamery, která bude použita, je Axis 213 PTZ (Pan, Tilt, Zoom). Tato kamera podporuje všechny vyžadované funkce, tj. natáčení objektivu, přiblížení a vzdálení snímaného objektu, a má
3
integrovaný HTTP server, který dovolí s kamerou komunikovat nad TCP/IP sítí přes protokol HTTP. Více informací o této kameře je možné získat z webových stránek společnosti Axis. Konkrétní odkaz na podrobnější informace o kameře, společně o odkazem na několik veřejně přístupných kamer tohoto typu, je uveden v seznamu použité literatury a zdrojů.
Cisco IP telefon Za účelem snadnějšího vývoje aplikace bude použito simulátoru IP telefonu, zvaného Cisco IP Communicator (verze 2.1). Tato aplikace se totiž chová téměř zcela identicky jako klasický stolní Cisco IP telefon, pro který má být finální aplikace určena. Rozdíl (funkční) oproti současnému, nejnovějšímu, modelu Cisco IP telefonu spočívá pouze v rozlišení displeje. Z hlediska komunikace, resp. podporovaných XML objektů, se nijak neliší, takže aplikace bude bez problémů fungovat jak se simulátorem, tak i se skutečným telefonem (zřetel se bude muset brát pouze na ono zmíněné maximální rozlišení displeje). Rovněž bude použit i simulátor Cisco Communications Manager-u (resp. Cisco CallManager-u), tedy Cisco proprietární aplikace zajišťující „fungování“ IP telefonie a telefonů samotných (Cisco Communications Manager poskytuje telefonům, během jejich startu, firmware a konfiguraci). Simulátor, zvaný CallManager Simulator (CM-Sim), byl vyvinut také společností Cisco Systems. Dostupný je například jako součást elektronické přílohy knihy „Developing Cisco IP Phone Services“ (viz použitá literatura). Cílový Cisco IP telefon, pro který bude aplikace určena, je Cisco Unified IP Phone 7975G. Více informací o tomto telefonu lze získat na webových stránkách společnosti Cisco Systems (viz například odkaz uvedený na konci tohoto dokumentu, v seznamu použité literatury a zdrojů).
Middleware aplikace Vyvíjená aplikace bude z jedné strany zajišťovat komunikaci s IP telefonem a ze strany druhé komunikaci s IP kamerou. Implementována bude v programovacím jazyku Java a poběží na aplikačním serveru Apache Tomcat. Tento server byl zvolen z důvodu podpory Java Servletů a Java Server Pages. Aplikace bude sloužit jako middleware, který dovolí IP telefonu přistupovat ke službám IP kamery. Zajistí konverzi formátu požadavků a přizpůsobí video vysílané kamerou do podoby vhodné pro IP telefon (sekvence obrázků ve formátu PNG). Aplikace tedy bude zprostředkovatelem komunikace.
4
Základní princip fungování systému a vyvíjené middleware aplikace 1) V rámci počáteční inicializace získá telefon z Communications Manager-u (CallManageru) potřebný firmware a konfiguraci. Součástí konfigurace je i URL služeb, tzv. Services URL. To odkazuje na aplikaci běžící na serveru, která bude tyto služby zprostředkovávat. 2) Po stisknutí tlačítka Services Cisco IP telefonu, které bylo (během kroku 1) namapováno na URL obslužné aplikace, vyšle telefon HTTP request na toto URL. 3) Obslužná aplikace tento požadavek obslouží a vrátí zpět seznam dostupných služeb. Seznam služeb je vrácen v podobě definovaných a telefonem podporovaných XML objektů, které jsou posílány opět prostřednictvím HTTP protokolu. 4) Uživatel si ze seznamu dostupných služeb jednu zvolí. Zvolená služba je opět identifikována pomocí URL, které bylo předáno během kroku 3 v rámci XML objektu. Obslužná aplikace dané služby, běžící opět na nějakém (klidně i stejném) serveru, tento požadavek obslouží. Obsluha může proběhnout buď opět ve formě navrácení jiného seznamu dalších dostupných služeb – podporováno je tedy libovolně hluboké vnořování (procházení) seznamů či podseznamů různých služeb. Druhou možností obsluhy je navrácení informací vážících se k dané konkrétní, uživatelem vyžadované, služby. Cisco IP telefon podporuje dvě formy komunikace. První je klasická „požadavekodpověď“ komunikace, známá například z webu. Tedy klient-server architektura, kdy telefon je klientem a aplikace zajišťující obsluhu požadavků telefonu běží na serveru. Takovýto způsob se nazývá také PUSH komunikace (HTTP klient integrovaný v telefonu iniciuje požadavek na server). Druhou možností, jak komunikovat s telefonem, je využití web serveru, který je rovněž integrální součástí telefonu. Tento server je schopen obsloužit příchozí HTTP požadavky, resp. XML parser telefonu analyzuje příchozí XML objekt a vyvolá příslušnou, v příchozím objektu specifikovanou, akci. Provedenou akcí může například být zaslání HTTP požadavku na nějaké, v příchozím objektu uvedené, URL. To může sloužit buď k získání nějakých dat z telefonu, nebo k vyvolání další akce – požadavek zaslaný telefonem může směřovat k aplikaci, která telefonu vrátí data, jež telefon poté například zobrazí na svém displeji. Takovýto princip komunikace se nazývá anglickým termínem PULL. IP kamera bude ovládána prostřednictvím svého webového rozhraní. Požadavky na provedení akce (přiblížení, vzdálení či otočení objektivu kamery) budou zasílány ve formě HTTP zpráv (požadavků). Požadavky jsou sice iniciovány uživatelem (telefonem), ale vlastní HTTP zpráva bude zasílána až middleware aplikací, jako reakce na požadavek vzešlý z telefonu. Aplikace tedy plní roli prostředníka komunikace probíhající mezi telefonem a
5
kamerou. I když telefon podporuje HTTP komunikaci, čili mohl by odeslat požadavek na provedení akce přímo, nemůže být tato situace tímto způsobem řešena. Telefon by totiž, po zaslání tohoto požadavku, „čekal na odpověď“, kterou má prezentovat uživateli. Prezentovanou informací by se ale, špatně, stala odpověď kamery na zaslaný požadavek (například odpověď na požadavek otočení objektivu kamery) a ne nový, aktuální, snímek z kamery, který je, samozřejmě, uživatelem očekáván. Další úlohou middleware aplikace bude převod formátu video vysílání (Motion JPEG), přicházejícího z kamery, do sekvence obrázků formátu PNG, který je podporován Cisco IP telefony (JPEG obrázky podporovány nejsou). Middleware aplikace musí rovněž zajistit „současné“ obsluhování požadavků z více různých (podporovaných) telefonů, které mohou přistupovat k více různým (podporovaným) kamerám. Jinými slovy musí aplikace dovolit současné probíhání více různých relací „telefon-kamera“.
IP telefon Pod termínem IP telefon lze, v užším slova smyslu, rozumět klienta pro telefonii typu VoIP (Voice over IP, resp. Voice over Internet Protocol). IP telefon tedy zprostředkovává telefonní (komunikační) služby prostřednictvím VoIP technologií, čímž dovoluje provozování těchto služeb nad datovými sítěmi (jako například Internet), oproti klasickým, původním PSTN (Public Switch Telephone Network) či jiným systémům. Jedná se o telefonní přístroj komunikující prostřednictvím svého IP rozhraní (resp. pro svou komunikaci využívá protokoly rodiny TCP/IP, nebo i další proprietární protokoly běžící nad IP protokolem). Využívány jsou protokoly jako SIP (Session Initiation Protocol), SCCP (Skinny Client Control Protocol nebo zkráceně Skinny) nebo různé další protokoly, které například používá Skype.
Obr. 2 – Cisco IP Phone 7975G a bezdrátový Cisco IP Phone 7921G (zdroj: http://www.cisco.com/en/US/products/sw/voicesw/index.html)
V širším slova smyslu můžeme pod termínem IP telefon chápat každé koncové zařízení pro IP telefonii, tedy jak samostatný přístroj, tak i software (tzv. softphone)
6
umožňující provozovat telefonní služby. Samostatné přístroje (tj. dedikované hardwarové zařízení) jsou „podobné“ klasickým analogovým či ISDN (Integrated Services Digital Network) telefonům. Původní analogový telefon může přistoupit k datové sítí a komunikovat prostřednictvím protokolů používaných IP telefony pomocí zařízení ATA (Analog Telephony Adapter), které zajišťuje potřebou konverzi mezi odlišnými formami komunikace (PSTN-toVoIP). ISDN telefon pak může pro tyto účely využít terminálového adaptéru TA (Terminal Adapter).
Obr. 3 – Cisco IP Communicator 2.1 (Softphone) (zdroj: http://www.cisco.com/en/US/products/sw/voicesw/index.html)
Jednou z hlavním motivací pro zavádění IP telefonie je snižování nákladů. Při využití IP telefonie totiž komunikace probíhá po stejných datových linkách jako například používají počítače pro přenos dat (dochází ke konvergenci hlasových a datových služeb). Pokud tedy hovor probíhá přes Internet, pak se platí i pouze jeden (obvykle fixní) poplatek za připojení právě k Internetu. Další motivací je rovněž možnost provozovat i další služby, které vůbec nejsou klasickými (původními) telefony podporovány. Mezi hlavní součásti (ať už softwarové nebo hardwarové), které společně tvoří IP telefon, patří zejména: •
Hardware telefonu (většinou s integrovaným tří-portovým přepínačem)
•
DNS (Domain Name System) klient
•
DHCP (Dynamic Host Configuration Protocol) klient
•
Komunikační (signalizační) protokoly (SIP, H.323, Skinny, Skype, …)
•
RTP (Real-time Transport Protocol) stack
•
HTTP (Hypertext Transfer Protocol) server
•
XML (Extensible Markup Language) parser
•
Uživatelské rozhraní
Pod hardwarem telefonu se rozumí komponenty jako jsou mikrofon, reproduktor, displej, numerická klávesnice a řada dalších ovládacích tlačítek. Dále pak procesor pro zpracování aplikační logiky – tzv. GPP (General Purpose Processor), voice-engine (softwarový subsystém zajišťující obousměrnou hlasovou komunikaci) nebo procesor pro 7
zpracování signálů (DSP neboli Digital Signal Processor) a pro zpracování RTP zpráv (GPP a DSP může být i kombinován na jednom čipu), analogově-digitální (A/D) a digitálněanalogové (D/A) převodníky, rozhraní pro připojení k síti (Ethernet, WiFi, …), zdroj napájení (externí adaptér, baterie či napájení po Ethernetu – IEEE 802.3af/PoE (Institute of Electrical and Electronics Engineers; Power over Ethernet). Ostatní komponenty pak zajišťují komunikaci v rámci sítě, resp. prezentují informace uživateli IP telefonu.
Vývoj služeb určených pro Cisco IP telefony Klíčové komponenty síťové architektury z pohledu vytváření služeb pro IP telefony Následující obrázek znázorňuje části typické korporátní sítě podporující chod IP telefonie a zajišťující možnost vytváření nových služeb určených pro IP telefony.
Obr. 4 – Klíčové komponenty síťové architektury z pohledu vytváření nových služeb pro IP telefony (zdroj: převzato z knihy Developing Cisco IP Phone Services)
Z pohledu vyvíjení služeb pro Cisco IP telefony lze síť zjednodušit na (rozlišovat pouze) následující komponenty: •
IP telefon (IP Phone)
•
Communications Manager (CallManager)
•
Web server (aplikační server)
V rámci reálné sítě přitom může být zapojena spousta (stovky až tisíce) IP telefonů, jejichž chod zajišťuje více (cluster) Communications Manager-ů. Přístup telefonů ke službám
8
je zajištěn pomocí webových (aplikačních) serverů, které mohou být zapojeny buď přímo do stejné lokální sítě jako telefony, nebo se tyto webové servery mohou nacházet kdekoli jinde v Internetu.
Aplikační protokoly či protokoly vyšších vrstev zajišťující chod služeb IP telefonů Protokoly vyšších vrstev OSI (Open Systems Interconnection) modelu popisují výměnu větších datových jednotek mezi stanicemi připojenými do sítě. Z hlediska vývoje služeb pro IP telefony jsou významné zejména dále uvedené protokoly. Prvním důležitým protokolem je Skinny Client Control Protocol (SCCP nebo také Skinny). Jedná se o proprietární protokol vyvinutý společností Cisco Systems pomocí nějž komunikují Cisco IP telefony s Communications Manager-em. SCCP využívá pro přenos svých zpráv protokolu TCP (Transmission Control Protocol) a slouží pro zasílání informací a příkazů mezi telefony a Communications Manager-em. Detaily jeho činnosti však nejsou z hlediska vývoje služeb podstatné. Po sestavení hovoru mezi dvěma telefony jsou vlastní voice (hlasové) pakety, tj. zprávy přenášející v nějaké formě uložená hlasová data uživatele, vyměňována pomocí protokolu RTP (Real-Time Transport Protocol). Tento protokol využívá pro transport svých zpráv protokolu UDP (User Datagram Protocol) a je speciálně určen pro přenos hlasových, video nebo jiných (multimediálních) zpráv, které jsou tzv. časově citlivé. Detaily tohoto protokolu opět nejsou nijak podstatné z hlediska vytváření nových služeb. Pro přístup k „webově-orientovaným“ službám se využívá HTTP (Hypertext Transfer Protocol) protokolu. Díky integrovanému HTTP klientovi může Cisco IP telefon komunikovat s webovým serverem. Takovýmto postupem, tj. HTTP požadavkem zaslaným serveru přistupuje telefon ke službám serveru. Druhou možností je, díky integraci HTTP serveru přímo v Cisco IP telefonu, komunikace s opačným průběhem. Tedy jiné zařízení může zaslat HTTP požadavek telefonu a vyžádat si tak provedení nějaké služby právě tímto telefonem. Toto je také možnost jak telefonu zasílat asynchronní příkazy.
9
Obr. 5 – Protokoly vyšších vrstev využívané IP telefony při komunikaci (zdroj: převzato z knihy Developing Cisco IP Phone Services)
Jak by mohlo vypadat nasazení jednotlivých komunikačních protokolů v reálné situaci naznačuje výše uvedený obrázek. Pro sestavení hovoru využívá telefon služeb Communications Manager-u, se kterým komunikuje pomocí zpráv Skinny (SCCP) protokolu. Voice data hovoru jsou pak mezi oběma telefony přenášena RTP protokolem. V jakémkoli okamžiku, ať už v době probíhajícího hovoru nebo v klidovém stavu, může telefon využitím HTTP protokolu přistoupit k dalším službám. Z obrázku je rovněž patrné, že přístup k dalším službám je zcela nezávislý na Communications Manager-u (vyjma iniciálního přiřazení základního URL tlačítku Services, což se děje při zapnutí nebo restartování telefonu, po stažení a následném aplikování konfigurace). Toto odlišuje tyto IP telefony od tradičních, byť moderních PBX (Public Branch Exchange) telefonů, které jsou fyzicky limitovány pro komunikaci s pouze pro ně určenou, proprietární pobočkovou ústřednou (PBX). Naproti tomu jsou IP telefony navrženy tak, že mohou komunikovat s libovolným jiným „IP kompatibilním“ zařízením, jakým může být Web server, mail server či jiné zařízení komunikující nad IP rozhraním. Telefon tedy využívá protokoly jako jsou HTTP, RTP a Skinny. Jejich hluboká znalost však není z pohledu vytváření nových služeb vůbec důležitá, či vůbec nutná. Pro komunikaci s telefonem stačí umět použít HTTP protokolu pro přenos aplikačních dat. Z hlediska přístupu ke službám se Cisco IP telefon chová podobně jako webový prohlížeč a zařízení (aplikace) služby poskytující pak jako webový server. Komunikace probíhá na bázi klient-server módu a data jsou vyměňována pomocí HTTP protokolu, který je jednak poměrně jednoduchým protokolem, jednak je již i historicky úspěšný (ověřený). Vzhledem k omezeným zobrazovacím možnostem displeje současných IP telefonů a k menšímu výpočetnímu výkonu telefonu nelze pracovat s přímo webovými stránkami určenými pro klasické počítače. Z tohoto důvodu byly pro definici obsahu a významu dat určených pro Cisco IP telefony specifikovány proprietární XML (Extensible Markup
10
Language) objekty, resp. XML elementy (tag-y). HTTP protokolu je pak využíváno jakožto transportního mechanizmu XML objektů telefonům určených. Kromě XML objektů lze telefonu pomocí HTTP protokolu předat i prostý textový soubor či webovou stránku (nebo jiná data), tento obsah je však pouze zobrazen displeji telefonu, bez jakékoli možnosti specifikovat jeho další význam. XML, oproti předchozímu, umožňuje vytvářet i poměrně silné, interaktivní aplikace. Mezi hlavní možnosti, které XML vývojářům aplikací přináší, patří především: •
Definice a zobrazení menu, které dovolí uživatelům provádět výběr ze seznamu dostupných položek.
•
Mapování tlačítek (tzv. soft-tlačítek) na nějakou funkcionalitu (což umožní například definování adresáře kontaktů a automatické vytočení odpovídajícího telefonního čísla po provedení volby uživatelem).
•
Zobrazovaní obrázků či vytváření grafických menu.
•
Vyvolání nějaké akce přímo IP telefonem.
Z jiného úhlu můžeme na HTTP nahlížet jako na obálku XML objektu, která tento objekt zapouzdřuje a zajišťuje doručení k jeho cíli. Pomocí XML, jakožto značkovacího jazyku, je pak možné definovat význam doručovaných dat. Jako ukázka velmi jednoduché služby, kterou lze vytvořit pro Cisco IP telefon, může být prosté stažení obrázku z webového serveru a jeho zobrazení na displeji telefonu. Po zapnutí si telefon nejprve stáhne potřebná data z Communications Manager-u. K tomu, aby tato data mohl stáhnout, potřebuje IP rozhraní (svou IP adresu), nad kterým bude komunikovat, a dále samozřejmě musí znát IP adresu Communications Manager-u. Rovněž je většinou potřebné znát i IP adresu výchozí brány. Všechny tyto informace (konfigurace IP komunikace), může získat z DHCP serveru. IP adresa, síťová maska a IP adresa výchozí brány patří ke standardním informacím právě DHCP serverem poskytovaným. IP adresa Communications Manager-u je předávána rovněž prostřednictvím DHCP protokolu a to pomocí jeho rozšiřujících položek, tzv. options, konkrétně pomocí položky 150, což je adresa TFTP (Trivial File Transfer Protocol) serveru. Po obdržení potřebné konfigurace pro komunikaci v rámci sítě může dojít k registraci u Communications Manager-u a následnému stažení firmware a konfigurace (obsahující mimo jiné i mapování tlačítka Services na URL služeb).
11
Obr. 6 – Stažení firmware a konfigurace a následný přístup ke službám
V rámci své konfigurace, kterou telefon obdržel od Communications Manager-u, je tedy i URL služeb, které odkazuje na webový (aplikační) server a které je namapováno na tlačítko Services. Po stisknutí tohoto tlačítka telefon, prostřednictvím svého HTTP klienta, vyšle požadavek (HTTP request) na ono URL. Server tento požadavek zpracuje a odpoví na něj opět pomocí HTTP protokolu, přičemž do dat odesílaných v této odpovědi začlení XML objekt, kterému Cisco IP telefon „rozumí“ (podporuje jej) a dokáže jej zpracovat.
Obr. 7 – XML objekt sloužící pro předání reference na obrázek
Odpověď telefonu, ve formě XML objektu, může vypadat například tak, jak je zobrazeno na výše uvedeném „obrázku“. Jedná se o velice jednoduchý XML objekt, jehož kořenový element se nazývá CiscoIPPhoneImageFile. Jak již z názvu objektu a jeho obsahu vyplývá, slouží tento XML objekt pro předání reference (URL) na soubor ve formátu PNG, který telefon automaticky ze specifikovaného místa stáhne a následně zobrazí na svém displeji. Soubor samozřejmě musí splňovat podmínky dané omezenějšími zobrazovacími schopnostmi telefonu (rozlišení, počet barev). Pomocí dalších elementů lze definovat titul či pozici obrázku na displeji. V obecném případě může mít tento XML objekt ještě více elementů. Seznam všech XML objektů podporovaných Cisco IP telefony, včetně jejich možných elementů, je uveden v příloze tohoto dokumentu.
12
3. Grafické formáty Grafických formátů pro ukládání různých obrázků je v dnešní době mnoho. Někdy je proto obtížné se mezi nimi přesně orientovat a pro danou aplikaci (uložení konkrétního obrázku) vybrat ten nejvhodnější. Grafické formáty se dají rozdělit do základních skupin podle několika podstatných hledisek. Asi nejhlavnějším hlediskem je způsob ukládání obrazových dat. Prvním způsobem je reprezentace obrazových dat pomocí soustavy (matice) bodů, tzv. pixelů, pro které se definuje jejich barva. Druhou možností je reprezentace soustavou matematických obrazců, jako jsou přímky, trojúhelníky nebo kruhy, u kterých se specifikuje jejich tvar, pozice a barva. Prvním zmiňovaným způsobem je tzv. rastrová grafika, druhým je tzv. vektorová grafika. Rastrové grafické formáty jsou v současné době dominantní, s vektorovými se dnes běžně nesetkáme. Další dělení formátů vychází ze způsobu jejich komprese. Ta může být ztrátová, nebo bezeztrátová. Algoritmy založené na ztrátové kompresi během svého provádění zahazují část grafické informace. Výsledný obrázek již při dekompresi není možné zcela obnovit do původního tvaru. Naopak, bezeztrátové formáty si i po komprimaci obsahu uchovávají možnost obnovy obrázku do podoby identické s původní předlohou. Nejznámějším zástupcem ztrátového formátu je JPEG, zástupcem bezeztrátových formátů je například PNG.
Obr. 8 – Porovnání kvality obrázků ve formátu JPEG z různou mírou ztrátovosti (kvality Q) (zdroj: http://en.wikipedia.org/wiki/JPEG)
13
JPEG (Joint Picture Experts Group) JPEG je běžně používanou metodou ztrátové komprese pro ukládání obrázků ve fotorealistické kvalitě. Zkratka JPEG vychází z názvu výboru, který tento formát vytvořil. Plný název tohoto výboru (či skupiny) je Joint Picture Experts Group. Skupina vznikla v roce 1986 a svůj standard vydala v roce 1992. O dva roky později, tedy v roce 1994, byl tento standard schválen a přijat organizací ISO (International Organization for Standardization) pod označením ISO 10918-1 (tedy de facto až od této doby se JPEG stal standardem). JPEG standard specifikuje jak kodek, tak i formát souboru. Kodek definuje způsob, jakým je obrázek komprimován do posloupnosti (streamu) bajtů a rovněž i způsob opačný, tedy dekompresi zpět k původnímu obrázku. Formát souboru říká, jakým způsobem je posloupnost (stream) bajtů uchovávána (uložena). Kompresní metoda JPEG je ztrátová. Kvůli ztrátovosti dochází v určité míře k nevratnému snížení kvality během procesu JPEG komprese. Dekompresí již nemůže být původní obrázek obnoven v kvalitě stejné, jako tomu bylo před kompresí. Míra komprese (kompresní poměr) poté definuje míru ztrátovosti a tím pádem snížení kvality. Čím vyšší kompresní poměr, tím větší ztráty při kompresi a z toho plynoucí horší kvalita obrázku. Na druhou stranu, samozřejmě, vzrůstající kompresní poměr snižuje velikost obrázku. Dále existuje také tzv. prokládaný „Progressive JPEG“ formát, který dovoluje kompresi ve více vrstvách s postupně se zvyšujícími detaily. Takovýto způsob komprese je vhodný pro přenos obrázků přes linky o malé přenosové rychlosti, kdy při stažení první části může být zobrazen náhled obrázku o nízké kvalitě a dále, během stahování dalších vrstev, lze postupně detaily doplňovat a zvyšovat kvalitu zobrazeného obrázku. Tento formát však není nijak široce podporován. Formát souboru je znám pod názvem „JPEG Interchange Format“ (JIF), což je specifikováno v rámci Annex B standardu. Vzhledem k náročnosti programování kodérů a dekodérů plně implementujících všechny aspekty standardu a dále s přihlédnutím k některým dalším nedostatkům je však tento původní formát pouze zřídkakdy používán. Z důvodu řešení neduhů tohoto původního standardu bylo vydáno i několik dalších standardů. Prvním z nich, vydaným v roce 1992, je „JPEG File Interchange Format“ (JFIF). Tento standard byl dále následován „Exchangeable image file format“ (Exif) a ICC (International Color Consortium) profily. Ve výše zmíněném textu o JPEG se občas zaměňují dva pojmy, resp. občas se vyskytuje drobná nepřesnost. Striktně je JPEG pouze název kompresní metody. Obrázky, které jsou uloženy v souborech s příponou jpg nebo jpeg (nebo s jinou, k tomuto formátu
14
patřící, příponou), jsou ve formátu JFIF (alternativně v původním JIF, či Exif), který využívá právě kompresní metodu JPEG. Avšak zkratka JPEG se mezi veřejností zažila i pro označení formátu souboru. Většina aplikací dovolujících uložit (vytvořit) „JPEG soubor (obrázek)“ ve skutečnosti vytváří soubor ve formátu JFIF a/nebo Exif. To je možné díky velké podobnosti (téměř shodě) obou formátů. Rozdíly spočívají například v pořadí tzv. aplikačních segmentů (Application Segment) a v tom, že oba standardy specifikují své vlastní aplikační segmenty (dávají jim svůj vlastní význam) a uvozují je svými vlastními speciálními značkami (ASCII sekvence znaků). I když se tedy většinou hovoří o souboru JPEG, míní se tím obvykle soubor JFIF, nebo soubor Exif JPEG. Existuje ovšem více formátů souborů založených na kompresi JPEG, například JNG (JPEG Network Graphics). Nejčastějšími koncovkami souborů ve formátu JPEG jsou jpg a jpeg, dále ale i jpe, jfif a jif.
Obr. 9 – Porovnání komprese JPEG/JFIF a JPEG 2000 (zdroj: http://en.wikipedia.org/wiki/JPEG_2000)
JPEG/JFIF je nejčastější formát používaný pro přenášení a ukládání fotografií na webu (nebo i v jiných aplikacích). Pro tyto účely je mnohem lepší než GIF (Graphics Interchange Format), který používá paletu s maximálně 256 různými barvami (používá pouze osm bitů na pixel), oproti potřebě vyjádřit tisíce (či dokonce milióny) barev obsažených ve fotografii. Pro publikování fotografií na webu je JPEG rovněž vhodnější než PNG (Portable Network Graphics), jelikož JPEG využívá ztrátovou kompresi (fotografie uložené v tomto formátu zabírají méně místa), zatímco PNG využívá bezeztrátové komprese, z čehož pramení i větší
15
velikost fotografií v tomto formátu uložených. JPEG však není vhodný pro perokresbu, zobrazení textu nebo ikony, protože kompresní metoda JPEG vytváří v takovém obrazu viditelné a rušivé artefakty. Pro takové účely se obvykle používají právě formáty PNG nebo GIF. MIME (Multipurpose Internet Mail Extensions) typ pro formát JFIF je image/jpeg (definováno v RFC 1341).
Obr. 10 – Jiné porovnání JPEG a JPEG 2000 (zdroj: http://www.digineff.cz/cojeto/ruzne/jpg2000.html)
V dnešní době je již kompresní algoritmus JPEG překonán novým standardem JPEG 2000. Mezi zásady JPEG 2000 patří kvalitní komprese s nízkým bitovým tokem, možnost ztrátové i bezeztrátové komprese, odolnost proti chybám a založen je na tzv. vlnkové (wavelet) transformaci.
Obr. 11 – Původní JPEG komprese a nová vlnková (wavelet) komprese (ukázka wavelet komprese používané formátem LWF vyvinutým firmou Luratech); výsledky jsou poněkud zkreslené, jelikož je výše prezentovaný obrázek uložen ve formátu JPEG) (zdroj: http://www.digineff.cz/cojeto/ruzne/jpg2000.html)
PNG (Portable Network Graphics) Grafický formát PNG, plným názvem Portable Network Graphics, byl vytvořen konsorciem W3C (World Wide Web Consortium) a prvně představen 1. října 1996. Jeho druhá specifikace, která opravovala všechny chyby prvně vydané verze, byla uveřejněna 10.
16
listopadu 2003. Tato verze byla následně přijata organizací ISO jakožto standard ISO/IEC 15948:2003 (E). Jedním z cílů vytvoření tohoto formátu bylo nahradit patentovaný grafický formát GIF (Graphics Interchange Format) jeho volně použitelnou obdobou (GIF jakožto grafický formát byl a je sice volně použitelný, ale LZW komprese (LZW84 algoritmus), kterou používá, je patentem společnosti Unisys, čož z GIF formátu efektivně činí formát patentovaný). Dalším z cílů byla náhrada formátu TIFF (Tag Image File Format) v mnoha jeho běžných použitích. PNG svými vlastnostmi doplňuje formát JPEG. Oba dva tyto formáty se dají s výhodou používat například na Webu. Obecně je PNG grafickým formátem určeným pro bezeztrátovou kompresi rastrové grafiky. Dokáže zobrazovat grafiku do barevné hloubky až 48 bitů (což je velmi výrazná výhoda proti formátu GIF). Dále umí zpracovávat obrázky jak v režimu True color, tak i v režimu indexovaných barev, což dává velké možnosti v rozsahu barev od několika desítek barev při indexovaném režimu, po až několik milionů barev v True Color režimu. Z hlediska sémantického Webu je důležitá podpora další „meta“ informace, kterou lze k PNG obrázku přidat. Standardně, kromě uživatelsky definovaných textových polí, jsou dostupná tato pole: •
Title
Název obrázku
•
Author
Jméno tvůrce obrázku
•
Description
Popis obrázku
•
Copyright
Informace o autorských právech
•
Creation Time
Čas vytvoření obrázku
•
Software
Identifikace programu, který obrázek vytvořil
•
Disclaimer
Poučení o autorských právech
•
Warning
Varování o obsahu obrázku
•
Source
Zařízení použité pro vytvoření obrázku
•
Comment
Komentář k obrázku
Formát PNG je postaven na naprosté kompatibilitě na všech systémech a ve všech programech. To znamená, že každý obrázek musí vyhovovat standardu a pak (pokud tomu tak opravdu je) jej lze zobrazit v kterémkoli programu, který tento standard podporuje (implementuje). Standard rovněž definuje další možnosti, jako je například samostatné nastavení světlosti. Dále je v každém obrázku stanoveno, zda-li používá šedou škálu barev, nebo všechny barvy, z čehož se dále odvíjí jeho zpracování.
17
Stejně jako obrázky formátu GIF mohou být i PNG obrázky tzv. binárně průsvitné. Rovněž, podobně jako u formátů TIFF či TGA (Truevision TGA či TARGA grafický formát), je podporována i tzv. alfa průsvitnost, čili částečná průsvitnost obrázků. PNG je tedy grafickým formátem, který podporuje jak alfa kanál (alfa/částečnou průsvitnost), tak i binární průsvitnost.
Kdy se rozhodnout pro JPEG a kdy pro PNG? JPEG je ztrátovým grafickým formátem. Dnes, především díky jeho použití digitálními fotoaparáty, je nejznámějším a nejčastěji používaným formátem. Kompresní algoritmus JPEG formátu je optimalizován pro uložení fotografií v plné barevné hloubce 24 bitů, kde znatelně snižuje velikost výsledného souboru. Vhodný je tedy hlavně pro uložení fotografií, kdy dokáže poměrně významně redukovat velikost paměti potřebné pro uložení fotografie a to při zachování velmi dobré kvality. Naopak, JPEG se nehodí pro ukládání takové grafiky, kde dochází k ostrým přechodům mezi barvami – tyto přechody totiž rozmaže. Mezi takovéto případy typicky patří webová grafika, různé převody vektorových obrázků nebo například grafické uložení textu.
Obr. 12 – Porovnání JPEG versus PNG při ukládání textu (obrázku s ostrými přechody) (zdroj: http://www.emag.cz/graficke-formaty-i-jpeg-a-png/ a http://en.wikipedia.org/wiki/Portable_Network_Graphics)
PNG je formátem původně vyvinutým jako náhrada za patentovaný (placený) GIF (dnes již ale platnost licencí vypršela). PNG tedy není ani patentovaný ani placený (JPEG je rovněž volně použitelný). Jedná se o formát založený na bezeztrátové kompresi grafické informace pomocí algoritmu Deflate. Podporuje barevnou hloubku až do 32 bitů, kde je k 24 bitovému obrázku přidán 8 bitový alfa kanál, ve kterém se zaznamenávají stíny a podobné grafické efekty (průhlednost). Hodí se zejména pro ukládání webové grafiky a jiných exportů z vektorových grafických formátů. Ovšem už není tak vhodný pro ukládání fotografií.
18
Takovéto použití, samozřejmě, možné je, ale vzhledem k bezeztrátové kompresi je výsledný soubor (většinou) znatelně větší než u JPEG komprese.
Motion JPEG Motion JPEG, zkráceně také MJPEG či M-JPEG, je neformální označení pro multimediální formát, kde každý video snímek (frame) je samostatně komprimován do JPEG formátu (jakožto JPEG obrázek). MJPEG formát je často používán například digitálními IP kamerami. Motion JPEG využívá techniku intraframe komprese (kódování). Jinou metodou je tzv. interframe komprese (využívaná formátem MPEG), kdy se daný snímek (frame) komprimuje s využitím informace o bezprostředně předcházejících a (nebo) následujících snímcích, což vede k velmi dobré efektivitě komprese. Naproti tomu intraframe technika spočívá pouze v kompresi aktuálního snímku, což efektivně znamená vlastně klasickou kompresi obrázku. Nedá se však říci, že interframe technika je vždy lepší, protože má lepší kompresní poměr. Při ztrátě jednoho snímku, například během přenosu sítí, se již bezprostředně následující rámce (tvořící určitou, kompresním algoritmem definovanou, posloupnost) nepodaří správně sestavit (dekomprimovat). Intraframe technika tímto neduhem netrpí, jelikož každý snímek je komprimován samostatně, bez jakékoli vazby na snímky předcházející či za ním následující. Další rozdíl mezi oběma technikami spočívá v proměnnosti, resp. stálosti množství dat potřebných pro přenesení jednoho snímku. Zatímco intraframe technika potřebuje pro zakódování každého snímku zhruba stejné množství bitů (a vykazuje tedy stálost), interframe technika vyžaduje pro zakódování různých typů rámců i různě velké množství bitů (a vykazuje tedy proměnlivost paměťových či kapacitních nároků). Motion JPEG není standardizován. Každý z výrobců IP kamery proto může používat trochu odlišné varianty tohoto formátů, tj. JPEG obrázky mohou být „vkládány“ do vysílání odlišným způsobem. Většina testovaných IP kamer používá vkládání JPEG obrázků, které je v souladu s níže uvedeným detailnějším rozborem Motion JPEG vysílání z kamery Axis 213 PTZ. Proto byla i aplikace napsána tak, aby podporovala IP kamery využívající právě takovýto formát vysílání. Jiná situace panuje u vysílání Motion JPEG 2000. Jak je z názvu patrno, v tomto vysílání je již pro obrázky využíváno formátu (kódování) JPEG 2000, tedy „vlnkové transformace“. ISO normou specifikující Motion JPEG 2000 je ISO/IEC 15444-3:2007 (zkratka IEC pochází z úplného názvu International Electrotechnical Commission). Tento typ vysílání však není stávajícími kamery příliš podporován.
19
Detailnější rozbor Motion JPEG vysílání z IP kamery Axis 213 PTZ Mezi (middleware) aplikací a IP kamerou je navázáno HTTP spojení (tj. HTTP-overTCP-over-IP). Z hlediska aplikace tudíž komunikace probíhá prostřednictvím výměny zpráv přenášených v rámci datové nálože HTTP protokolu. Zbylá síťová komunikace je, v souladu s klasickým procesem zapouzdření (enkapsulace a deenkapsulace), pro aplikaci zcela transparentní (samozřejmě po nutném navázání spojení, ke kterému je nutné znát IP adresu (či symbolické vyjádření přeložitelné službou DNS), cílový TCP port (HTTP serveru kamery) a vlastní komunikační protokol, tedy v tomto případě HTTP a jeho další parametry, hlavně umístění a název „webové stránky“, na níž chceme přistoupit).
Obr. 13 – Přenos Motion JPEG vysílání (streamu) v rámci HTTP dat mezi aplikací a IP kamerou
V rámci dat HTTP protokolu se přenáší Motion JPEG vysílání (stream), tedy vlastní snímky zachycené objektivem IP kamery a komprimované jakožto JPEG obrázky. Se žádostí aplikace o čtení dalších dat IP kamera postupně zasílá další a další JPEG obrázky (snímky). Jeden obrázek však nemusí být, a typicky není, přenášen vcelku, tj. v rámci jedné datové HTTP, TCP a IP komunikační jednotky (resp. v rámci jednoho PDU, Protocol Data Unit). V jednom konkrétním případě byl jeden JPEG obrázek přenášen celkem 35 IP pakety. Ke sledování probíhajícího spojení mezi aplikací a IP kamerou, resp. sledování přenosu obrázků v rámci Motion JPEG streamu, lze využít nějakého analyzátoru síťového provozu, jakým je například aplikace Wireshark.
Obr. 14 – Ukázka výstupu aplikace Wireshark použité pro sledování Motion JPEG vysílání (streamu)
20
Z výše prezentovaného výstupu aplikace Wireshark je nejprve patrné navázání TCP spojení mezi aplikací a IP kamerou, tzv. TCP 3-way handshake. Následuje žádost HTTP GET o přístup k (stahování) Motion JPEG vysílání (GET /mjpg/video.mjpg). Poté již probíhá výměna HTTP dat právě nad TCP protokolem. Z další analýzy dat je pak možné vysledovat, že první přenášený JPEG obrázek je přenášen počínaje šestým IP paketem. Toto lze zjistit nalezením speciální sekvence 0xFFD8 (přehled těchto speciálních sekvencí je uveden v příloze), kterou musí začínat každý JPEG obrázek. K nalezení této sekvence lze opět s výhodou použít aplikace Wireshark, která nabízí možnost vyhledání konkrétního paketu obsahujícího specifikovanou „šestnáctkovou“ hodnotu (tj. v našem případě onen začátek JPEG obrázku uvozený hodnotou 0xFFD8).
Obr. 15 – Analýza HTTP dat – identifikace začátku JPEG obrázku nalezením speciální sekvence 0xFFD8, rovněž je patrný i typ přenášených dat a jejich délka
Konec JPEG obrázku je identifikován rovněž pomocí speciální sekvence, tentokrát prostřednictvím šestnáctkové hodnoty 0xFFD9. Ta se, v tomto konkrétním případě, nachází v rámci dat čtyřicátého IP paketu. Ve stejném IP paketu jsou pak přenášena data i následujícího JPEG obrázku, opět uvozeného sekvencí 0xFFD8. Vše je ukázáno na následujícím obrázku.
Obr. 16 – Analýza HTTP dat – identifikace konce JPEG obrázku (0xFFD9) a následného začátku dalšího JPEG obrázku (0xFFD8) zasílaného v rámci Motion JPEG vysílání (streamu)
21
Analyzovaná data, v našem případě data šestého IP paketu, můžeme dále exportovat z aplikace Wireshark a zobrazit je v textové podobě.
Obr. 17 – Textová podoba analyzovaných dat – nejprve je prezentována HTTP hlavička, následuje oddělovač individuálního JPEG obrázku v rámci Motion JPEG vysílání (streamu), dále JPEG hlavička (s uvozovací sekvencí 0xFFD8) a vlastní data obrázku
Jelikož aplikace komunikuje nad HTTP protokolem, není z jejího hlediska HTTP hlavička „vidět“ (ale dalo by se k ní přistoupit). Prvními daty, která se k aplikaci „dostanou“ jsou v tomto případě (tedy v případě HTTP zprávy přenášené šestým IP paketem) oddělovače (separátory) individuálního JPEG obrázku v rámci Motion JPEG vysílání (streamu). Separátorem se rozumí nějaká data o libovolné, klidně i nulové délce (data, která nejsou součástí JPEG obrázku), zakončená oddělovačem řádků (speciální sekvencí „\n“, „nový řádek“, resp. „šestnáctkovou“ hodnotou 0x0a). Obdobně můžeme analyzovat data, v našem případě čtyřicátého IP paketu, ve kterých je patrný konec jednoho JPEG obrázku a začátek dalšího.
Obr. 18 – Textová podoba analyzovaných dat – na začátku jsou data prvního JPEG obrázku, následuje speciální sekvence označující konec prvního JPEG obrázku (0xFFD9) a koncový oddělovač (nový řádek), poté jsou prezentovány počáteční oddělovače JPEG obrázku, za nimi počáteční uvozovací sekvence (0xFFD8) a vlastní data druhého JPEG obrázku
22
Z výše uvedené analýzy Motion JPEG vysílání (streamu) z IP kamery Axis 213 PTZ je patrné, že jednotlivé JPEG obrázky jsou mezi sebou odděleny čtyřmi počátečními a jedním koncovým separátorem. Takovýmto způsobem je tedy možné provést analýzu dat libovolné jiné IP kamery, ověřit tak formát Motion JPEG vysílání a v případě podporovaného (tj. výše analyzovaného) formátu nalézt počet počátečních a koncových separátorů, které jsou součástí vstupních dat pro konfiguraci aplikace, a zajistit tak úspěšnou komunikaci s touto IP kamerou.
Obr. 19 – Čtyři počáteční a jeden koncový oddělovač JPEG obrázků používaný IP kamerou Axis 213 PTZ
23
4. Návrh aplikace CiscoIPPhoneIPCameraService Aplikace CiscoIPPhoneIPCameraService má umožnit Cisco IP telefonu spojení s IP kamerou ve smyslu zobrazení snímků snímaných objektivem kamery na displeji telefonu a dále, dle možností kamery, dovolit telefonu kameru ovládat (otáčet objektivem, přibližovat či vzdalovat snímaný objekt). Aplikace tedy plní roli prostředníka komunikace. Z jedné strany komunikuje s telefonem, přijímá jeho požadavky na spojení s kamerou či na ovládání kamery a poskytuje telefonu aktuální snímky z dané IP kamery. Z druhé strany komunikuje s IP kamerou, navazuje a ukončuje spojení s touto kamerou, přijímá a dále zpracovává Motion JPEG vysílání (stream) kamerou poskytované. Aplikace má přitom dovolit obecně více telefonům přistupovat k jedné nebo i více kamerám „současně“ (tedy dovolit probíhání více souběžných relací „telefon-kamera“). Z hlediska co možná největšího odstínění konkrétních detailů a proprietárních řešení komunikačních rozhraní IP kamer různých výrobců byla zvolena metoda komunikace prostřednictvím HTTP protokolu. Navíc se zároveň jedná i o typické řešení, podporované napříč výrobci IP kamer a napříč portfoliem všech IP kamer konkrétního výrobce. Tedy, téměř každá IP kamera implementuje svůj vlastní webový (HTTP) server, který dokáže přijmout požadavky na zasílání snímků kamerou pořízených a případně i další požadavky na ovládání kamery či nějaké jiné úkony. Jiná, takto výhodná a široce podporovaná alternativa k „HTTP ovládání“, není dostupná. Pro potřeby aplikace je dále vhodné využít Motion JPEG vysílání, jelikož se telefonu stejně musí zasílat individuální obrázky samostatně, tedy například MPEG vysílání dnešní Cisco IP telefony zatím zpracovat nedokáží. Vzhledem k pevně danému rozhraní pro vývoj služeb Cisco IP telefonů musí, alespoň část, aplikace běžet na webovém serveru. Programovacím jazykem pro implementaci aplikace byla zvolena Java (J2EE platforma). Z důvodu abstrahování implementace nejrůznějších komunikačních protokolů či jiných komponent potřebných pro chod aplikace, které však nejsou předmětem této práce a tudíž by bylo jednak nesmyslné, jednak i vlastně nemožné (časově) se jim věnovat, se aplikace opře o použití již existujících open-source projektů, které již řadu problémů spojených i s vývojem této aplikace vyřešily. Nejvýznamnějším projektem pak bude projekt Jakarta („The Jakarta Project“, nebo taky „The Apache Jakarta Project“). Aplikace, vzhledem k potřebě podpory Java Servlet a Java Server Pages (JSP), poběží na Apache Tomcat aplikačním serveru (konkrétně na Apache Tomcat 6.0, podporujícím Servlet/JPS 2.5/2.1 specifikaci). Z hlediska bezpečnosti se předpokládá s nasazením aplikace, telefonů a kamer buď v rámci interní sítě společnosti, kde se počítá s tím, že autentizace aplikace s telefonem či kamerou nebude vyžadována. Alternativně se počítá se spojením s volně přístupnou kamerou 24
dostupnou v Internetu. Pokud by z nějakého důvodu bylo třeba chránit aplikaci (a kameru či telefony) před přístupem neoprávněných uživatelů, předpokládá se, že zabezpečení přístupu bude (v rámci interní sítě) řešeno síťovou infrastrukturou. Pro realizaci zabezpečeného spojení přes veřejnou síť (Internet) by se s výhodou použilo VPN (Virtual Private Network) technologie. Takovéto řešení by navíc, z hlediska komunikace aplikace-kamera či aplikacetelefon, bylo zcela transparentní. Administrace aplikace, tj. konfigurace parametrů potřebných pro běh vlastní aplikace, definování a nastavení nové IP kamery, se kterou má systém spolupracovat (komunikovat), eventuelně změna parametrů existující (v systému již registrované) kamery, či smazání nějaké kamery bude realizováno přes webové rozhraní aplikace. Takto vložená data o kamerách budou uložena v XML souboru (případně ve více souborech) a/nebo v databázi.
Jakarta projekt a Apache Tomcat Jakarta (nebo také Apache Jakarta) je projektem organizace Apache Software Foundation, jehož cílem je vytvářet kvalitní open-source řešení serverových aplikací pro Java platformu. V současné době se jedná o asi nejkomplexnější, volně šířitelné řešení pro serverové aplikace. Apache Tomcat je jedním ze stěžejních Jakarta projektů. Jedná se o relativně jednoduchý tzv. Servlet/JSP zásobník (container). Zároveň je Apache Tomcat oficiální, referenční implementací (J2EE) technologií Java Servlet a Java Server Pages (JSP), jež jsou vyvíjeny pod záštitou společnosti Sun Microsystems. Díky této vlastnosti budou Servlety/JSP fungující nad Tomcat fungovat rovněž nad jakýmkoli jiným, J2EE certifikovaným serverem. Dále Tomcat podporuje i další nástroje umožňující vývoj a nasazení webových aplikací a webových služeb. V současné době aktuální verze Apache Tomcat 6.0.16 zajišťuje podporu Java Servlet, resp. JSP, specifikace 2.5, resp. 2.1. Tomcat je vhodný, zejména pro svoji relativní jednoduchost, bezproblémovou instalaci a nulovou cenu, pro vývoj JSP a dalších aplikací pro použití v nekomerčních, spíše menších, projektech. Aplikace Tomcat umí vyřizovat požadavky HTTP a to nejen na servlety, ale také na statické stránky, případně tyto požadavky přesměrovávat dále, apod. Dalo by se tedy říci, že Tomcat obsahuje webový server. Oproti například webovému serveru Apache je omezen co se možnosti různého nastavení a vyladění týče a rovněž není zdaleka tak efektivní. Proto je vhodné používat Tomcat v kombinaci s nějakým webovým serverem, kdy tento webový server uspokojuje všechny příchozí požadavky a pouze ty, které jsou určené přímo pro Tomcat, na něj dále přesměrovává.
25
Java Servlet a Java Server Pages Servlety a JSP vznikly jako odpověď technologie Java na programování serverových aplikací pomocí technologií CGI (Common Gateway Interface) a PHP (PHP: Hypertext Preprocessor).
Obr. 20 – Znázornění „života“ JSP stránky (zdroj: http://en.wikipedia.org/wiki/Servlet)
Servlet je program napsaný v jazyce Java, který běží na serveru, a který dokáže zpracovávat požadavky zaslané pomocí HTTP protokolu a následně na ně dokáže HTTP protokolem odpovídat. V podstatě lze říci, že každý servlet je malý, samostatný webový server. Na aplikaci typu Tomcat lze nahlížet jakožto na zásobník (container) servetů, který se stará o jejich spouštění, běh, ukončení, komunikaci s klienty a další věci. V podstatě by bylo možné zpracovávat i požadavky jiných druhů serverů (nejen HTTP), ale v praxi se jiné použití, než právě pro HTTP neuchytilo, a proto se dnes, místo HTTP Servlet, používá pouze zkrácené označení Servlet.
26
Obr. 21 – Ukázka „HelloWorld“ servletu (jedná se o výsek zdrojového kódu vygenerovaného vývojovým prostředím NetBeans 6.0)
Jak by mohla vypadat velmi jednoduchá, dynamicky, pomocí Servletu vygenerovaná webová stránka, znázorňuje následující „oříznutý snímek“ okna prohlížeče Mozilla Firefox.
Obr. 22 – Výstup „HelloWorld“ servletu zobrazený ve webovém prohlížeči Mozilla Firefox
JSP je technologie umožňující směšovat statické HTML stránky s dynamicky generovaným obsahem a je jistou analogií s technologiemi jako jsou ASP (Active Server Pages) či PHP. JSP stránky je možno používat i samostatně, ale podstatně lepší je využití „spolupráce“ JSP a Servletů. Servlet samotný je totiž poměrně nešikovný jako nástroj pro vytváření statického HTML kódu (pro příklad poněkud těžkopádný zápis out.println("
MyWebPage"); oproti prostému HTML kódu). JSP se proto s
výhodou používá ke směšování statických částí HTML stránek, napsaných v klasickém HTML kódu, s dynamickými částmi, které jsou vytvářeny pomocí servletu.
27
Java Beans Java Bean je speciální třída, ke které můžeme přistupovat z JPS stránky a instance jíž se používá například pro obsluhu formuláře. K instanci této třídy se přistupuje pomocí referencí přímo z JSP stránky. Aby takovýto mechanizmus mohl fungovat, musí být dodrženy určité konvence definované (zavedené) společností Sun Microsystems. Java Beans se většinou používají k programování webových aplikací nebo tzv. Java Enterprise aplikací (Enterprise Java Beans). Instance Java Beans jsou kumulovány v kontejneru (Tomcat) a přistupujeme k nim pomocí předem definované reference.
Obr. 23 – Ukázka metod „getter“ a „setter“ pro (privátní) proměnnou value (typu String)
Konvence Java Beans K proměnným se přistupuje pouze pomocí tzv. setterů a getterů. Tyto názvy pocházejí z konvence pro pojmenovávání metod. Je-li ve třídě (Java Bean-u) definovaná nějaká proměnná, dejme tomu proměnná s názvem value, potom k ní přistupujeme pomocí metod public typ-proměnné getValue(), resp. public void setValue(typ-proměnné nová-hodnota). V případě proměnných booleovského (logického; boolean) typu je pak možné (ale ne nutné) namísto „getteru“ implementovat tzv. is metodu, tj. public boolean isValue(). Tyto „is“ metody se rozpoznávají a volají na Bean-u až při běhu programu.
Uchovávání informací o registrovaných IP kamerách Aplikace podporuje dvě možnosti ukládání dat, resp. dva různé zdroje jejich získání. První možností je využití MySQL databáze jakožto datového zdroje a úložiště. Druhá alternativa spočívá v „lokálním uložení“ dat, tj. uložení v rámci souborového systému, který je implementován nad pevným diskem stanice na níž tato aplikace (resp. Tomcat server) běží. V případě této varianty jsou informace o známých IP kamerách ukládány v XML souboru.
28
Obr. 24 – Propojení aplikace s MySQL databází
V rámci konfigurace aplikace lze definovat, zda se budou používat obě dostupné varianty pro uložení, resp. načtení dat, či zda bude použita pouze jedna konkrétní varianta. Při použití obou možností se pak specifikuje preference jedné z variant. Preference spočívá v tom, že se nejprve budou načítat IP kamery z uprostředňovaného úložiště a až poté dojde k načtení kamer ze zbývajícího (druhého) zdroje. V případě opakovaného výskytu stejného názvu IP kamery v druhém úložišti nedojde k načtení této kamery (tj. kamery s duplicitním název) a při následném uložení bude tato duplicita nahrazena jedinou, z preferovaného úložiště získanou, variantou. Všechny ostatní (neduplicitní) záznamy budou slity dohromady, dojde tedy k synchronizaci obou zdrojů (databáze a XML souboru). Komunikace s databází probíhá pomocí JDBC ovladačů (driverů), přičemž každý typ databáze má své specifické ovladače. Realizována je nad TCP/IP komunikačními protokoly (IP sítí).
JDBC (Java Database Connectivity) Java Database Connectivity (JDBC) je aplikační rozhraní (API) pro programovací jazyk Java, které definuje způsob, jakým mohou klienti přistupovat k databázi. Poskytuje metody pro kladení dotazů nad databází (vkládání, odstraňování či měnění dat). Orientováno je na zajištění přístupu k relační databázi. JDBC rozhraní (API) je mezivrstvou mezi Java aplikací a vlastní komunikací s databází. JDBC dovoluje zasílat (provádět) SQL (Structured Query Language, neboli strukturovaný dotazovací jazyk) a PL/SQL (Procedural Language/SQL) dotazy databázi. Datové typy SQL databáze lze získat z výsledku SQL dotazu jako instance Java tříd. Naopak JDBC ovladač (driver) dokáže vkládat instance Java tříd do SQL dotazů a správně, v
29
závislosti na zvolené databázi, je uložit, upravit, apod. Takto lze vytvořit aplikaci nezávislou na zvoleném databázovém stroji. Nicméně stále je třeba psát dotazy v SQL.
Obr. 25 – JDBC architektura (zdroj: http://www.jdbc-tutorial.com/)
Java 2 Platform Standard Edition (J2SE) podporuje JDBC 3.0 API společně s referenční implementací JDBC-to-ODBC Bridge, což dovoluje připojení k jakémukoli ODBC podporujícímu datovému úložišti. ODBC (Open Database Connectivity) poskytuje metody (standardní softwarové API) pro přístup k DBMS (Database Management Systems). Navrženo bylo tak, aby bylo nezávislé na konkrétním programovacím jazyku, databázovém i operačním systému. ODBC specifikace nabízí procedurální rozhraní pro přístup k datům prostřednictvím SQL dotazů.
JDBC ovladač (driver) Pro realizaci spojení s konkrétní databází potřebuje JDBC také její specifický ovladač (driver). JDBC ovladač dovoluje realizovat spojení s databází a implementuje protokol pro jak přenos dotazů majících se nad databází provést, tak pro přenos výsledku dotazu nad databází provedeného. Možností jak realizovat připojení k databázi a komunikaci s touto databází (tj. možností jak realizovat JDBC driver) je více. Každá je poplatná určité situaci, která je odvislá od rozhraní implementovaného konkrétní databází. První možností je použití JDBC-ODBC bridge, který zprostředkovává komunikaci s databází přes ODBC rozhraní (tj. jak tento ovladač, tak i databáze implementují ODBC rozhraní). Druhou variantou je v rámci JDBC ovladače přímo implementovat nativní rozhraní (klientské funkce) dané databáze. Takovémuto typu driveru se říká „Native-API driver“. Třetí varianta spočívá v realizaci spojení přes middle-ware aplikaci, která je schopna obsloužit přímo metody JDBC, tj. přijmout volání JDBC metod a konvertovat je (nějakým způsobem, ať už přímo, nebo nepřímo) na volání funkcí podporovaných rozhraním konkrétní databáze. Takovýto JDBC driver je také označován jako „Network-Protocol Driver“ nebo také jako „Pure Java Driver for Database Middleware“. Čtvrtý typ JDBC ovladače spočívá v implementaci specifického protokolu podporovaného danou databází, do jehož „zpráv se budou překládat JDBC metody“. Tento typ ovladače se označuje také jako „Native-Protocol Driver“ nebo jako „Direct to Database Pure Java Driver“. Každý z uvedených způsobů realizace JDBC ovladače (typu JDBC driveru) má, samozřejmě, své výhody i nevýhody.
30
JDBC-ODBC a ODBC-JDBC Bridge JDBC-ODBC Bridge se skládá z JDBC driveru, který využívá ODBC driver pro přístup k databázi. Tento ovladač (driver) transformuje volání JDBC metod na volaní ODBC funkcí. Takovýto bridge je používán pokud daná databáze nepodporuje JDBC driver (tj. „pure-Java“ nebo také „Java-nativní“ ovladač).
Obr. 26 – JDBC-ODBC bridge (JDBC driver type 1) (zdroj: http://en.wikipedia.org/wiki/JDBC_driver)
Výhodou JDBC-ODBC Bridge je možnost přistupovat k téměř jakékoli databázi (mající ODBC driver). Nevýhodou je pak zvýšená režie spojená s průchody a s nimi spojenými konverzemi přes více rozhraní. Dále musí být ODBC driver nainstalován i na straně klienta, což může být problém například při přistupování k databázi v apletech. ODBC-JDBC bridge je tvořen ODBC ovladačem (driverem), který využívá služeb JDBC driveru pro přístup k databázi. Využívá se tedy opačné konverze, než u JDBC-ODBC bridge, tj. překladu volání ODBC funkcí na volání metod JDBC ovladače. Tohoto bridge se využívá v situaci, kdy není k dispozici ODBC ovladač pro konkrétní databázi, ale JDBC driver dostupný je.
Native-API driver Native-API realizace JDBC ovladače spočívá v implementaci klientské sady funkcí pro přístup ke konkrétní databázi. Tento ovladač překládá volané JDBC metody na volaní nativních funkcí API databáze. Jelikož je finální volání databázových funkcí realizováno „nejavovským“ kódem, není (nemůže být) takovýto typ ovladače čistou Java implementací, takže není ani univerzálně přenositelný. Ovladač musí být zkompilován pro nasazení v rámci konkrétního operačního systému. Další nevýhodou je omezenější dostupnost databází, jelikož 31
ne pro všechny databáze je takovýto ovladač dostupný. Rovněž, z důvodu potřeby specifického softwaru na straně klienta, je takovéto řešení nevhodné pro webové aplikace. Naproti tomu je ale výkonnost tohoto ovladače vyšší než u první varianty (JDBC-ODBC bridge), jelikož není nutné využívat právě „ODBC mezivrstvu“, čímž se sníží režie nutná pro realizaci komunikace.
Obr. 27 – Native-API ovladač (JDBC driver type 2) (zdroj: http://en.wikipedia.org/wiki/JDBC_driver)
Network-Protocol Driver (Pure Java Driver for Database Middleware) Třetí možností realizace JDBC driveru je Network-Protocol Driver nebo také tzv. „Pure Java Driver for Database Middleware“. Takováto implementace využívá služeb mezilehlé aplikace (middle-ware aplikace mezi klientem přistupujícím k databázi (JDBC ovladačem) a vlastní databází). Tato mezilehlá aplikace se nazývá také middle-tier (služba běžící na aplikačním serveru mezi klientem a databází). Middle-tier zajišťuje převod volaných JDBC metod na funkce podporované komunikačním rozhraním konkrétní databáze. Jinými slovy middle-tier provádí konverzi (ať už přímou, nebo nepřímou) JDBC volání na konkrétní komunikační protokol podporovaný danou databází.
32
Obr. 28 – Network-Protocol Driver (Pure Java Driver for Database Middleware; JDBC driver type 3) (zdroj: http://en.wikipedia.org/wiki/JDBC_driver)
Tento typ JDBC driveru je plně implementován v Javě (jedná se o „čistou“ Javu), takže je bez problémů přenositelný. Rovněž je nezávislý na konkrétní databázi. Databáze, které budou podporovány, jsou dány možnostmi mezilehlé aplikace (middle-tier). Další výhodou takovéto nepřímé komunikace s databází, tj. vlastně komunikace (mezi klientem a middleware aplikací) zcela nezávislé na databázi, je to, že na straně klienta není třeba žádný specifický software (ovladač databáze). Nevýhodou je ovšem vyšší režie spojená s komunikací přes více vrstev (rozhraní) a dále závislost na chodu middleware aplikace.
Native-Protocol Driver (Direct to Database Pure Java Driver) Native-Protocol JDBC ovladač spočívá v implementaci specifického protokolu podporovaného danou databází, do jehož zpráv „se budou překládat volané JDBC metody“. Native-Protocol JDBC driver je zcela implementován v Javě, proto je nezávislý na konkrétní platformě. Instalován je v rámci JVM (Java Virtual Machine) na straně klienta. Ve srovnání s výše uvedenými třemi typy JDBC ovladačů (tj. JDBC-ODBC bridge, Native-API driver a Network-Protocol Driver) nabízí lepší výkonnost, jelikož eliminuje režii konverze do ODBC, resp. nativních funkcí API databáze či režii spojenou s nepřímou komunikací přes middleware aplikaci. Nevýhodou je jeho závislost na konkrétním typu databáze (pro různé databáze potřebujeme jejich specifický ovladač).
33
Obr. 29 – Native-Protocol driver (Direct to Database Pure Java Driver; JDBC driver type 4) (zdroj: http://en.wikipedia.org/wiki/JDBC_driver)
XML soubor pro uchování informací o IP kamerách Kromě využití databáze pro uložení informací o známých IP kamerách budou tyto informace ukládány i do XML souboru na lokálním disku. XML nabízí možnost ukládání dat v dobře strukturované, hierarchické formě. Data jsou navíc ukládána v textovém formátu, takže mohou být zobrazena (čtena), případně i editována, pomocí běžných textových editorů.
Obr. 30 – Struktura XML souboru pro uchování informací o známých IP kamerách (v tomto případě je uvedena pouze jedna kamera, jejíž parametry jsou definované mezi elementy IPCamera)
34
Výhody a nevýhody ukládání dat do XML souboru respektive do databáze Vzhledem k tomu, že dat, se kterými aplikace pracuje (která se musí uchovávat) je poměrně málo, může se namísto databáze s výhodou použít lokálně uloženého XML souboru. Důvodů, proč se uchýlit k takovéto možnosti může být i více než jen pouze množství dat. Takto uložená data jsou totiž čitelná a velice snadno interpretovatelná koncovým uživatelem. Čitelnost vyplývá z textové formy, ve které jsou data uložena. Ze strukturovanosti dat pak plyne i snadná interpretovatelnost. XML soubor může být prohlížen či editován běžnými textovými editory. Data v databázi jsou často uložena v binární podobě, která je pro uživatele velice obtížně čitelná (formát dat je neprůhledný, často neznámý). Aplikace i rychleji startuje, protože není potřeba připojovat se k externí databázi. Rovněž není vůbec potřeba nějakou databázi provozovat. Vzhledem k povaze dat používaných touto aplikací – „data nejsou relační“ – lze právě takovýto přístup k jejich ukládání s výhodou použít. Nevýhodou ukládání dat v XML formátu je složitější (náročnější) implementace. V dnešní době sice existuje řada knihoven (či frameworků) podporujících práci s XML soubory, ale přesto nebude manipulace s nimi tak jednoduchá jako realizace například „select“ dotazu nad relací s MySQL databází. Rovněž práce s XML je pomalejší než práce s binárním formátem používaným konkrétní databází. Další nevýhodou XML proti použití databáze může být dostupnost dat. S databází se dnes typicky komunikuje nad TCP/IP sítí, což ji efektivně činí globálně dostupnou, dostupnost XML souboru uloženého například na lokálním pevném disku může být již horší (ale nutně tomu tak být nemusí, tento soubor může být vystaven například na nějakém webovém serveru). Další výhoda použití databáze může spočívat v přístupových právech k zápisu na lokální disk. Pokud budeme data ukládat do databáze, tak tato práva (přístupu k lokálnímu disku) samozřejmě nepotřebujeme. Při využití lokálního XML souboru jsou ovšem tato práva nezbytnou nutností. Této skutečnosti mohou s výhodou využít například Java aplety, které z bezpečnostních důvodů nemají práva číst a zapisovat na lokální disk.
Základy práce s databází v Javě Abychom mohli „v Javě pracovat s databází“, musíme provést několik základních kroků. Nejprve je třeba importovat balík java.sql (resp. potřebné třídy z tohoto balíku). Dalším krokem je načtení potřebného ovladače pro zajištění spojení a komunikace s použitou databází a vytvoření vlastního spojení (relace) s databází. Pro tyto účely použijeme nějakou variaci následujícího kódu:
Obr. 31 – Základy práce s databází v Javě (ukázkový kód 1)
35
Nejprve musíme nahrát konkrétní JDBC driver. K tomuto účelu slouží statická metoda forName(String jdbcDriver) třídy Class. Konkrétní syntaxe volání této metody pro načtení ovladače MySQL databáze může vypadat následovně:
Obr. 32 – Základy práce s databází v Javě (ukázkový kód 2)
Dle dokumentace (JavaDoc) se tato metoda „pokusí“ nalézt, nahrát a přilinkovat třídu či rozhraní. Nalezením se myslí proces, během kterého se k danému názvu třídy či rozhraní přiřadí její (jeho) binární forma (reprezentace; vlastní implementace) a zkonstruuje se objekt, který pak bude tuto třídu (toto rozhraní) reprezentovat. Linkováním je chápána transformace binární formy do podoby použitelné Java Virtual Machine (JVM). Nakonec dojde k inicializaci třídy, během níž jsou inicializovány statické, třídní proměnné a rovněž je provedena statická inicializační metoda. Tedy, po zavolání metody forName() se zavaděč tříd (classloader) pokusí načíst a přilinkovat třídu Driver v „com.mysql.jdbc“ balíku a v případě úspěchu je dále spuštěn statický inicializer. Statický inicializer třídy Driver vypadá následovně:
Obr. 33 – Základy práce s databází v Javě (statický inicializer třídy Driver)
Z výše uvedeného vyplývá, že během provedení tohoto inicializeru dojde, prostřednictvím statické metody registerDriver() třídy java.sql.DriverManager, k registraci právě objektu této třídy (inicializer zaregistruje sám sebe). Význam tohoto vyplývá z dalšího úseku kódu:
Obr. 34 – Základy práce s databází v Javě (ukázkový kód 3)
Třída DriverManager, při znalosti vstupních parametrů (JDBC URL, uživatelské jméno a heslo), vrací referenci na spojení s databází. Aby tedy bylo možné navázat spojení s databází, DriverManager třída musí znát databázový ovladač (JDBC driver), který chceme (se má) použít. Tento ovladač nalezne iterováním přes pole (interně se jedná o vektor) ovladačů, které byly zaregistrovány pomocí výše uvedené metody registerDriver(Driver driver) a následným voláním metody acceptsURL(url) nad každým ovladačem nalezeným
36
v poli (během iterování), čímž efektivně zjišťuje, zda je daný ovladač schopen obsloužit dané JDBC URL. Interaktovat s databází, resp. klást dotazy nad touto databází, můžeme nad vytvořeným spojením prostřednictvím objektu třídy Statement. Případné výstupní hodnoty (data načtená z databáze) jsou vráceny pomocí reference na objekt třídy ResultSet. Zkráceně (neúplně) by mohl vypadat zdrojový kód pro spojení s MySQL databází a provedení jednoho základního dotazu například následovně:
Obr. 35 – Ukázkový (neúplný) zdrojový kód v Javě pro spojení s MySQL databází a provedení jednoho základního dotazu
37
5. Popis aplikace CiscoIPPhoneIPCameraService Aplikace CiscoIPPhoneIPCameraService se skládá ze čtyř hlavních částí, které jsou zapouzdřeny do samostatných Java balíků. Mezi tyto čtyři balíky patří: •
image (třídy podporující práci s obrázky)
•
io (třídy pro manipulaci se soubory a databází)
•
ipCamera (třídy zajišťující připojení a spolupráci s IP kamerou)
•
webAndCiscoIPPhone (servlety a Java Bean-y zajišťující komunikační rozhraní pro IP telefony a dovolující administraci aplikace, plus třída MyHTTPClient)
Nad těmito balíky je třída ApplicationController, jejíž objekt je zodpovědný za poskytování (prostřednictvím svých metod) veškerých parametrů potřebných pro běh všech ostatních komponent systému. Aplikační kontrolér je, spolu se všemi balíky, zapouzdřen v balíku ciscoIPPhoneIPCameraService. Dále k těmto čtyřem balíkům a aplikačnímu kontroléru patří rovněž JSP stránky, které dále rozšiřují webové rozhraní aplikace.
Balík ciscoIPPhoneIPCameraService ciscoIPPhoneIPCameraService je „hlavním“ balíkem, který zapouzdřuje všechny
zbývající balíky aplikace. Tento balík obsahuje dvě třídy: •
ApplicationController
•
ApplicationException
Aplikační kontrolér (třída ApplicationController) Třída aplikačního kontroléru definuje jednak objekt této třídy (jeho metody a parametry), jednak statické (tj. třídní) metody a parametry. V rámci aplikace může v jednu chvíli existovat pouze jediná instance (jediný objekt) této třídy. Pro ostatní komponenty je objekt aplikačního kontroléru dostupný prostřednictvím veřejné, statické, třídní metody getApplicationController, která vrací referenci na tento objekt. V případě, že v době jejího volání objekt aplikačního kontroléru neexistuje, vytvoří tato metoda jeho instanci. Využívá se tedy tzv. lazy, resp. on-demand, inicializace, kdy je objekt třídy vytvářen skutečně až v době, kdy je potřeba jej využívat.
38
Obr. 36 – Konstruktor aplikačního kontroléru (validate je privátní, statická metoda)
Jak již bylo výše uvedeno, objekt aplikačního kontroléru je zodpovědný za poskytování (prostřednictvím svých metod) veškerých parametrů potřebných pro běh všech ostatních komponent systému. Díky tomuto objektu přidáváme další úroveň nepřímosti (indirection) pro odstínění detailů implementace dalších tříd s užší specializací. To je výhodné z hlediska konfigurace aplikace. Parametry potřebné pro běh jsou uchovávány aplikačním kontrolérem a ten je, prostřednictvím svých metod, poskytuje dalším objektům. Rovněž aplikační kontrolér poskytuje zbývajícím objektům některé metody, které mohou dále využívat (jako například načtení IP kamer z databáze či vstupního XML souboru).
Obr. 37 – Metoda getApplicationController (aplikace on-demand/lazy inicializace, proměnná appController je privátní, statická proměnná třídy ApplicationController)
Jelikož je v celé aplikaci třeba pouze jednoho objektu třídy ApplicationController a tento objekt bude přistupován napříč celým kódem, je třeba zajistit jeho univerzální viditelnost. Z těchto důvodů je přístup k němu, resp. vytváření instance třídy ApplicationController, řešen dle GoF (Gang of Four) návrhového vzoru Singleton. Tudíž, řešení spočívá v definování statické (třídní) metody, která vrací referenci na objekt aplikačního kontroléru (také se říká, že vrací singleton). V rámci této metody (viz výše uvedený „obrázek se zdrojovým kódem“) je aplikována tzv. lazy (nebo také on-demand) inicializace. K vytvoření objektu aplikačního kontroléru proto dojde až v době, kdy je skutečně potřeba jej využívat. Jelikož by v případě vícevláknového výpočtu představoval úsek kódu s rozhodovací sekcí („if (appController == null) …) sekci kritickou, je součástí definice metody uvedeno i klíčové slovo synchronized, které „zajistí atomičnost provedení“ této části kódu. Hlavní motivací takovéhoto návrhu aplikace bylo zajistit dostatečnou udržitelnost kódu, tj. dovolit co nejsnadnější provádění změn či různých úprav aplikace. Umělé zavedení aplikačního kontroléru a delegování zodpovědnosti za poskytování všech potřebných údajů a
39
služeb právě tomuto objektu k těmto požadavkům úspěšně vedlo. Parametry nutné pro běh aplikace (a vytvoření aplikačního kontroléru) se konfigurují přes webové rozhraní, což je také dnes standardní a velice snadno použitelný způsob.
Třída ApplicationException Tato třída obsahuje pouze definici výjimky, kterou mohou „vyhodit“ metody aplikačního kontroléru.
Balík image a třída ImageResizer V rámci balíku image se nachází pouze jediná třída ImageResizer, která obsahuje metodu pro změnu velikosti obrázku.
Balík io Balík io zapouzdřuje třídy pro manipulaci se soubory a databází. Obsahuje následující třídy: •
DatabaseHandler
•
ImageRemover
•
InputOutput
•
SAXHandler
•
XMLParser
Třída DatabaseHandler Třída DatabaseHandler obsahuje metody pro obsluhu MySQL databáze. Mezi implementované metody například patří readIPCameras, která slouží k načtení IP kamer uložených v databázi. V rámci této metody se vytvářejí instance třídy IPCamera (balík ipCamera), které reprezentují systémem známé IP kamery, se kterými je možné navázat spojení a z jejichž Motion JPEG vysílání systém dokáže extrahovat jednotlivé JPEG obrázky. Reference na instance objektů třídy IPCamera se automaticky ukládají do spojového seznamu, který je definován rovněž ve třídě IPCamera (balík ipCamera). Metoda má jediný vstupní parametr, kterým je „double hodnota“ („reálné“ číslo) udávající dobu (v minutách), po jejíž uplynutí dojde k automatickému ukončení spojení s danou IP kamerou (samozřejmě pouze pokud obraz z této kamery není požadován žádným z uživatelů aplikace (resp. žádným telefonem)). Metoda vrací počet načtených kamer (jakožto integer).
40
Dále tato třída, samozřejmě, obsahuje i metodu saveIPCamerasIntoDatabase, která, jak z názvu plyne, slouží k uložení IP kamer do databáze. Jejím vstupním parametrem je reference na spojový seznam (LinkedList) kamer, které se mají uložit. V závislosti na úspěchu, resp. neúspěchu uložení kamer do databáze vrací metoda logickou hodnotu true, resp. false. Třída ImageRemover Objekt třídy ImageRemover je „odstraňovačem“ obrázků. Jelikož lze Cisco IP telefonu předat pouze referenci na PNG obrázek ve formě URL odkazujícího na daný obrázek, který je vystavený na webovém serveru, nelze, bez nějakého dalšího sledovaní aktivity serveru, zjistit, zda již telefon obrázek z webového serveru stáhnul. Takováto informace je důležitá z hlediska možnosti pozdějšího smazání obrázku, který již není třeba uchovávat. Tato situace je tedy řešena pomocí specializované třídy, jejíž objekty se automaticky postarají o odstranění takovéhoto (starého, již nepotřebného) obrázku. Díky implementaci rozhraní Runnable mohou být objekty této třídy spouštěny jako samostatně běžící vlákna.
Obr. 38 – Konstruktor objektů třídy ImageRemover
Konstruktor objektu třídy ImageRemover má dva vstupní parametry. Prvním je úplná cesta k obrázku společně s jeho názvem (tj. identifikace obrázku v rámci lokálního souborového systému), druhým parametrem je doba, po kterou má odstraňovač obrázků počkat, než provede vlastní výmaz (doba je udávána jako celé číslo vyjadřující počet vteřin). Pomocí této doby tedy lze naplánovat odstranění souboru (obrázku). Konstruktor poté vytvoří vlákno sama sebe a spustí jej pomocí metody start. Doba, po kterou se bude před odstraněním obrázku čekat, je ve výchozím nastavení rovna deseti vteřinám. Toto výchozí chování lze ovlivnit změnou hodnoty konstanty WAIT_BEFORE_ERASING_IMAGE_SEC definované ve třídě ImageRequestsHandler (balík webAndCiscoIPPhone). Instance třídy ImageRemover se vytváří ihned po uložení obrázku (a jeho vystavení na webovém serveru), který má být následně tímto odstraňovačem smazán.
Třída InputOutput InputOutput třída obsahuje metodu pro uložení seznamu známých (v systému
registrovaných) IP kamer do XML souboru. Konkrétně se jedná o metodu saveIPCameras,
41
která má tři vstupní parametry. Prvním je spojový seznam (LinkedList) IP kamer, které se mají uložit. Druhým je název výstupního XML souboru a třetím pak úplná cesta, kam má být výstupní soubor uložen. Dle úspěchu, resp. neúspěchu uložení metoda vrací logickou hodnotu true, resp. false.
Třída SAXHandler Třída SAXHandler obsahuje definice metod potřebných pro provedení syntaktické analýzy vstupního XML souboru. Její definice plyne z potřeb použitého SAX (Simple API for XML) parseru.
Třída XMLParser XMLParser zajišťuje parsování (syntaktickou analýzu) vstupního XML souboru.
Pomocí SAX parseru se ze vstupního XML souboru (z jeho dat) vytvoří DOM (Document Object Model). Mezi metody třídy XMLParser patří readIPCameraData. Tato metoda slouží k načtení IP kamer ze vstupního XML souboru a má dva vstupní parametry. Prvním je úplná cesta ke vstupnímu souboru, druhým je pak název tohoto souboru. Podobně jako tomu bylo u metody readIPCameras třídy DatabaseHandler (stejného balíku), dochází během provádění této metody k vytváření instancí třídy IPCamera (balík ipCamera), které reprezentují systémem známé IP kamery. Reference na instance těchto objektů se automaticky ukládají do spojového seznamu, který je definován ve třídě IPCamera (balík ipCamera).
Balík ipCamera V balíku ipCamera jsou lokalizovány třídy zajišťující podporu pro komunikaci s IP kamerami. Mezi třídy, které tento balík zapouzdřuje, patří: •
IPCamera
•
IPCameraException
•
IPCameraStopper
Třída IPCamera IPCamera je třídou, která zajišťuje spojení s IP kamerou. Díky tomu, že implementuje
rozhraní Runnable, mohou být její instance spouštěny jakožto samostatná vlákna. Instance této třídy dokáže poskytnout aktuální obrázek z IP kamery, kterou tento objekt reprezentuje (tj. se kterou komunikuje). 42
Obr. 39 – Konstruktor objektů třídy IPCamera
Objekty třídy IPCamera jsou vytvářeny pomocí konstruktoru, který má dva vstupní parametry. Prvním parametrem je symbolický název IP kamery, pod kterým bude kamera v systému identifikována. Zároveň bude tento název použit v rámci seznamu dostupných kamer, který bude předáván IP telefonům. Název kamery musí být jedinečný a zároveň nesmí obsahovat mezery (což je ošetřeno validací při načítání vstupních dat). V případě pokusu vložit kameru s názvem, který by se shodoval s již existujícím (v systému zaregistrovaným) názvem kamery, dojde k vyhození výjimky IPCameraException. Kontrola shody názvů je implementována v metodě insertIPCamera. Dalším použitím symbolického názvu IP kamery je jeho začlenění do názvu obrázku z této kamery, který bude vystaven na webovém serveru, aby si jej mohl IP telefon stáhnout. Konkrétně je název kamery prefixem kompletního názvu obrázku. Během vytváření objektu této třídy se dále nastavují dva příznaky – connected a stop. Příznak connected říká, zda je s kamerou skutečně navázáno spojení (což během vytváření instance neplatí) a příznak stop indikuje požadavek na to, aby bylo spojení s kamerou ukončeno (jeho hodnota se testuje v rámci nekonečné smyčky, ve které dochází k načítání Motion JPEG vysílání). Posledním úkolem konstruktoru je vytvořit nový objekt třídy IPCameraStopper, tedy jakéhosi zastavovače IP kamery. IPCameraStopper je vlákno, kterému se při vytváření předá reference na instanci IP kamery, kterou má po uplynutí určité doby, dané dalším vstupním parametrem stopCameraAfterMin, zastavit (samozřejmě k zastavení dojde pouze pokud neexistují požadavky na stahování obrázků z dané IP kamery). Po vytvoření zastavovače kamery dojde i k jeho spuštění, tj. vlastně naplánování zastavení dané kamery. Mezi metody podporované touto třídou určitě patří connect a disconnect. Jejich účel vyplývá již z jejich názvu. Connect dokáže navázat HTTP spojení s IP kamerou, přičemž toto spojení je „otevíráno (navazováno) na Motion JPEG URL“, které je jedním z parametrů
43
objektu IP kamery, který je nastavován při vkládání kamery do systému (externím subjektem, který IP kameru vytváří). Disconnect pak toto spojení ukončí. Další metodou je readStreamFromIPCamera. Ta dokáže načítat Motion JPEG vysílání a vydělovat z něj jednotlivé JPEG obrázky. Metoda má jeden vstupní parametr, který říká, zda se má provádět nekonečné čtení (ukončované testováním příznaku stop), či zda se má načíst pouze jeden obrázek.
Obr. 40 – Metoda saveImage objektu třídy IPCamera
Pokud je požadován (telefonem) aktuální obrázek z IP kamery, čili je potřeba tento obrázek vystavit (uložit) na webovém serveru, tak je volána metoda saveImage (opět objektu této třídy). Jejími třemi vstupními parametry jsou úplná cesta, kam se má obrázek uložit, uvedená společně s názvem obrázku, dále je to šířka a výška obrázku (tedy rozlišení v „pixelech“). Tato metoda tudíž, před uložením obrázku, ještě volá statickou (třídní) metodu resizeImageSimple (třída ImageResizer, balík image), pomocí které upraví velikost obrázku dle požadovaných parametrů. Obrázek je ukládán ve formátu PNG. Dalšími důležitými metodami, tentokráte statickými (třídními) metodami, je trojice insertIPCamera, removeIPCamera a getIPCamera. Metoda insertIPCamera je veřejná, statická metoda, jejímž úkolem je vložení IP kamery (předané jakožto jediný vstupní parametr) do spojového seznamu všech známých kamer. Jak již bylo výše uvedeno, název každé kamery musí být unikátní, takže tato metoda musí právě tuto jedinečnost názvu, při vkládání nové kamery, ověřit. Pro případné odstranění IP kamery pak slouží statická metoda removeIPCamera, která má jediný vstupní parametr a sice název kamery, která má být odstraněna. K získání reference na objekt již registrované kamery slouží statická metoda getIPCamera. Referenci vrací dle jediného vstupního parametru, opět symbolického názvu IP kamery. Hlavní metoda vlákna, tj. metoda run, nejprve naváže spojení s IP kamerou (pomocí metody connect) a poté zavolá metodu readStreamFromIPCamera, která zajistí načítání
44
vstupního Motion JPEG vysílání. Tělo run končí voláním metody disconnect, tedy odpojením od dané kamery. Pro předčasné probuzení automatického zastavovače IP kamery (vytvořeného a naplánovaného konstruktorem objektů této třídy) slouží metoda interruptIPCameraStopper. Předčasné probuzení stopovače efektivně znamená jeho opětovné naplánování, tj. znovuuspání na dobu danou jeho parametrem stopCameraAfterMin. Metoda interruptIPCameraStopper je volána při každém požadavku na čtení aktuálního obrázku z dané kamery (tj. vlastně požadavku na vystavení aktuálního obrázku na webovém serveru).
Obr. 41 – Metoda moveRight objektu třídy IPCamera
K dalším metodám patří tzv. control, move a zoom metody. Ty jsou volány pokud existuje požadavek související s ovládáním kamery. Ke „control“ požadavkům patří zahájení spojení s kamerou, ukončení spojení a tzv. „wild“ požadavek (míněno jako volně definovatelný typ požadavku). Mezi „move“ akce patří čtyři směry natáčení objektivu kamery (tedy otočení vpravo, vlevo, nahoru a dolů), „zoom“ akce jsou dvě, první je přiblížení objektu snímaného kamerou (zoom in) a druhou akcí je naopak oddálení snímaného objektu (zoom out). Spojení s kamerou je realizováno vytvořením a spuštěním vlákna instance dané IP kamery. Vzhledem k existenci a využití automatického zastavovače kamery není metoda ukončení spojení využívána. Všechny zbylé metody fungují tak, že vytvoří novou instanci třídy MyHTTPClient (balík webAndCiscoIPPhone), kterou lze spustit jako samostatně běžící vlákno a která, dle vstupních parametrů, dokáže zaslat HTTP požadavek (GET nebo POST), prostřednictvím kterého je daná akce mající se s IP kamerou provést realizována. Metodou setCookie lze „ručně nastavit“ cookie, které bude v HTTP hlavičce požadavku zaslána IP kameře. Nastavení cookie může být některými kamerami vyžadováno pro ovládání (některé kamery podporují možnost vyhrazení si právě této kamery a poté, právě pomocí cookie se identifikuje autorizovaný uživatel, tedy relace daného uživatele).
Třída IPCameraException Tato třída obsahuje pouze definici výjimky, kterou mohou „vyhodit“ metody (objektu) třídy IPCamera.
45
Třída IPCameraStopper
Obr. 42 – Hlavní metoda (run) vlákna IPCameraStopper (ipc je privátní proměnná referencující objekt třídy IPCamera)
Třída IPCameraStopper, neboli „zastavovač IP kamery“, je, díky zdědění třídy Thread, vláknem. Její instance tedy mohou být spouštěny jako samostatně běžící vlákna. Objekty jsou vytvářeny konstruktorem, který má dva vstupní parametry. Prvním je reference na objekt třídy IPCamera, tj. kamera, nad kterou bude tento zastavovač operovat (bude ukončovat spojení
s touto kamerou). Druhým je doba stopCameraAfterMin, po jejíž uplynutí má zastavovač ukončit spojení. Ta je předávána jako „reálné“ číslo (double) a je interpretovaná jako počet minut. Ukončení spojení je prováděno periodicky (nekonečněkrát), vždy po uplynutí výše zmíněného intervalu. Případné předčasné probuzení stopovače má efektivně význam neprovedení ukončení spojení s kamerou v aktuálně probíhajícím „intervalu“ (v aktuální periodě) a přeplánování stopovače (jeho opětovné uspání na plnou dobu stanovenou intervalem stopCameraAfterMin).
Balík webAndCiscoIPPhone Balík webAndCiscoIPPhone zapouzdřuje Servlety, Java Bean-y a třídu MyHTTPClient. Servlety a Java Bean-y zajišťují komunikační rozhraní pro IP telefony a dovolují administraci aplikace (možnosti administrace jsou dále rozšířeny pomocí JPS stránek). Třída MyHTTPClient dovoluje zasílat HTTP požadavky. Mezi třídy nacházející se v balíku webAndCiscoIPPhone patří: •
AdministrationBean
•
IPCameraFormBean
•
IPCameraService
•
IPPhoneServices
46
•
ImageRequestsHandler
•
MyHTTPClient
•
RegisteredIPCameras
Třída (Java Bean) AdministrationBean Třída AdministrationBean je vlastně Java Bean. Z toho vyplývá, že obsahuje všechny potřebné tzv. gettery a settery, tj. metody „get“, resp. „set“ pro získání, resp. nastavení hodnoty proměnných používaných v rámci HTML formuláře, který je definován například v JSP stránce a který se používá pro načtení potřebných vstupních dat (administrace aplikace či vložení informací o IP kameře).
Obr. 43 – Ukázka „getter“ a „setter“ metod pro proměnnou username (typu String)
Jak již bylo výše uvedeno, aby mohla „být nějaká třída Java Bean-em“, musí dodržovat určité konvence (správě definovat „getter“ a „setter“ metody). Pak tuto třídu můžeme referencovat z JSP stránky a využívat všechny její metody.
Obr. 44 – Možná definice vstupního pole pro zadání textu (zde uživatelského jména) v HTML formuláři definovaném v JSP stránce
Třídy (Bean-u) AdministrationBean využíváme pro zpracování vstupních dat nutných pro rozeběhnutí aplikace. Data jsou vyplňována a odesílána přes webový formulář. Pomocí objektu této třídy jsou dále propagována do systému (k aplikačnímu kontroléru).
Obr. 45 – Příklad definice (element jsp:useBean) reference na AdministrationBean v JSP stránce a nastavení všech proměnných (element jsp:setProperty), tj. vlastně volání metod „setter“
Z využití třídy AdministrationBean pro zpracování dat nutných pro rozeběhnutí celé aplikace plyne poměrně důležitá zodpovědnost této třídy. Tou je vytvoření objektu
47
aplikačního kontroléru (tj. instance třídy ApplicationController), čímž efektivně dojde k nastartování aplikace (služby ovládání IP kamery dostupné pro Cisco IP telefony). Pro vytvoření aplikačního kontroléru (a nastartování aplikace) slouží veřejná instanční metoda startApplication. Metoda vnitřně pracuje tak, že nejprve provede validaci (svých) vstupních
dat získaných z webového formuláře. Pokud jsou data validní (použitelná), tak metoda inicializuje aplikační kontrolér (pomocí jeho veřejných statických metod) a následně se pokusí vytvořit objekt aplikačního kontroléru (skryto za voláním metody getApplicationController třídy ApplicationController). Aplikační kontrolér ještě provádí vlastní
validaci dat, která byla nastavena právě instancí třídy AdministrationBean. Volání metody startApplication (již objektu) aplikačního kontroléru pak vede k načtení kamer (z databáze,
XML souboru, nebo obojího). Metoda vrací, dle úspěchu, resp. neúspěchu provedení výše zmíněného, logickou hodnotu (boolean) true, resp. false.
Obr. 46 – Zkrácená verze instanční metody startApplication třídy AdministrationBean
Dále tato třída obsahuje metodu saveCameras pro uložení kamer. Vnitřně ale dojde pouze k delegování zodpovědnosti za uložení kamer na aplikační kontrolér. Metoda vrací buď true, nebo false, opět podle úspěchu, nebo neúspěchu uložení kamer.
Třída (Java Bean) IPCameraFormBean Třída IPCameraFormBean je opět Java Bean. Tento bean je spjat s formulářem sloužícím pro registraci nové IP kamery. Opět obsahuje nezbytné „getter“ a „setter“ metody. Rovněž je dostupná metoda validate pro validaci vstupních dat (dat načtených z webového formuláře).
48
Dále obsahuje metodu registerIPCameraInSystem, která slouží pro registraci nové IP kamery v systému. Tato metoda nejprve provede validaci vstupních dat (dat o nové IP kameře) a pokud jsou data v pořádku, vytvoří novou instanci IP kamery (resp. se o to pokusí, pokud již není název kamery v systému použit, tak se tento pokus zdaří) a nastaví všechny její parametry (Motion JPEG URL, ovládací URL, …). Dle úspěchu či neúspěchu registrace kamery vrací true či false. Tato metoda ovšem kamery (novou kameru) neukládá, pro uložení je nutné využít instanční metody saveAllIPCameras aplikačního kontroléru.
Třída (Servlet) IPCameraService Servlet IPCameraService je vstupním webovým (XML) rozhraním služby ovládání IP kamery pomocí Cisco IP telefonu. Dokáže obsloužit příchozí HTTP požadavky (jak GET, tak i POST metody). Konkrétně vrací seznam dostupných IP kamer, tj. kamer registrovaných v systému. To se děje pomocí metody sendIPCamerasOffer. V případě, že služba neběží (není vytvořena instance aplikačního kontroléru), dokáže tento servlet odeslat hlášku o této situaci pomocí metody sendAlertNotification.
Třída (Servlet) IPPhoneServices Tento servlet poskytuje základní komunikační rozhraní pro poskytování služeb Cisco IP telefonům. Je to jakési obecné rozhraní, které vrací nabídku „všech možných“ služeb pro Cisco IP telefony. Nabídka těchto služeb se odesílá pomocí metody sendServicesOffer, ve které je, přirozeně, i odkaz na službu ovládání IP kamery (tj. odkaz na servlet IPCameraService). V případě, že služba neběží (není vytvořena instance aplikačního kontroléru), dokáže tento servlet (stejně jako IPCameraService) odeslat hlášku o této situaci pomocí metody sendAlertNotification.
Třída (Servlet) ImageRequestsHandler Servlet ImageRequestsHandler má na starosti obsluhu požadavků na stažení obrázku z konkrétní IP kamery. Jelikož je komunikace prostřednictvím HTTP protokolu bezestavová, je nutné nějakým způsobem zajistit identifikaci relace „telefon-kamera“, tj. identifikovat kameru, ze které chce daný telefon stáhnout aktuální obrázek. Pro tyto účely je vhodné využít parametru cookie HTTP hlavičky. Parametr cookie se nastavuje při prvotním přístupu na tento servlet (tedy na servlet ImageRequestsHandler). Prvotní přístup nějakého telefonu (resp. prvotní přístup v rámci nějaké konkrétní relace „telefon-kamera“) je detekován přítomností (GET) parametru „camera“. Z nabídky IP kamer, kterou telefon obdržel od servletu IPCameraService, si uživatel vybere konkrétní kameru. URL, které je namapováno IPCameraService servletem na nějakou kameru, obsahuje právě jakožto GET parametr „camera“ hodnotu odpovídající názvu dané IP kamery. Tedy, pokud by například byl název 49
kamery „axis-greece“, pak by (zjednodušeně) byla tato kamera namapována na URL /ImageRequestsHandler?camera=axis-greece. Po prvotním přístupu je nastavena cookie s názvem „camera“ na hodnotu rovnou symbolickému názvu dané IP kamery (v našem příkladě by to byla hodnota axis-greece). Takovýmto řešením tedy, přesněji, identifikujeme relaci „(nějaký)telefon-(konkrétní)kamera“.
Obr. 47 – Identifikace relace „telefon-kamera“ pomocí HTTP Cookie „camera“
Další (opakované) požadavky na stažení obrázku z kamery již obsahují danou cookie a mohou být adekvátně obslouženy. Přitom následné požadavky (cílené na konkrétní kameru) mohou zároveň mít nastavenu hodnotu nějakého dalšího (GET) parametru. Tím může být požadavek na řízení spojení s kamerou – tzv. „control“ parametr, jenž může nabývat tří hodnot (start, stop, wild). Nebo požadavek na pohyb (natočení) objektivu kamery – tzv. „move“ parametr, jehož čtyři možné hodnoty jsou right, left, up a down. Posledním parametrem, který může být předán je tzv. „zoom“ parametr. Ten může nabývat dvou hodnot, a sice in, nebo out. Nepřítomnost žádného z parametrů je vyhodnocena jako pouhá žádost o stažení aktuálního (nového) obrázku z dané IP kamery. Detekci přítomnosti cookie a dalších případných parametrů má na starosti metoda processRequest, která poté, dle vyhodnocení cookie a dalších parametrů volá další, specifičtější metody provádějící nějakou konkrétní činnost. Zároveň, právě dle hodnoty cookie (názvu kamery), pomocí statické metody getIPCamera třídy IPCamera, získá referenci na objekt tuto kameru reprezentující, který následně předává specifičtějším metodám obsluhujícím daný požadavek. Pokud není dostupný aktuální obrázek z nějaké kamery, odešle ImageRequestsHandler servlet pomocí své metody sendInitialImage tzv. iniciální obrázek (resp. URL vedoucí k tomuto obrázku). Ten lze definovat v rámci konfigurace aplikace.
50
Aktuální obrázek (resp. URL vedoucí k tomuto obrázku) je zasílán pomocí metody sendCurrentImage. Tato metoda musí, kromě odeslání XML objektu Cisco IP telefonu, vyžádat z dané IP kamery aktuální obrázek, resp. nechat jej uložit na webovém serveru prostřednictvím instanční metody saveCurrentImage třídy IPCamera. Po uložení obrázku rovněž naplánuje jeho odstranění, to se děje vytvořením nové instance (vlákna) ImageRemover. Doba, za kterou bude obrázek smazán, je dána hodnotou konstanty WAIT_BEFORE_ERASING_IMAGE_SEC, která je ve výchozím stavu nastavena na deset vteřin.
Pomocí dalších tří metod processControlParameter, processMoveParameter a processZoomParameter určených pro zpracování (reakci na) vstupních parametrů „control, move a zoom“ jsou volány odpovídající instanční metody „control, move a zoom“ definované ve třídě IPCamera. Součástí těchto metod je i zasílání aktuálního, popřípadě iniciálního obrázku (tj. volání adekvátní metod pro tyto účely). Metoda sendSoftKeysMapping je využívána pro zasílání mapování „soft-tlačítek“ telefonu na konkrétní službu. V případě, že služba neběží (není vytvořena instance aplikačního kontroléru), dokáže tento servlet rovněž odeslat hlášku o této situaci (a to pomocí metody sendAlertNotification).
Třída MyHTTPClient Třída MyHTTPClient dovoluje zaslat HTTP požadavek (GET nebo POST) na uvedené URL. Díky implementaci rozhraní Runnable mohou být její instance spouštěny jako samostatně běžící vlákna. Dále, prostřednictvím instanční metody setCookie, dovoluje nastavit parametr cookie. Pro odeslání HTTP požadavku jsou k dispozici dvě metody, a sice sendHTTPRequestGET a sendHTTPRequestPOST. První slouží pro zaslání HTTP GET, druhá pak pro zaslání HTTP POST. Nutností (vzhledem k implementaci rozhraní Runnable) je implementace hlavní metody vlákna, tedy metody run, která, dle nastavených parametrů (definovaných při vytváření instance konstruktorem), provede odeslání HTTP požadavku.
Třída (Servlet) RegisteredIPCameras Servlet RegisteredIPCameras slouží pro zobrazení kamer registrovaných v systému. Kromě zobrazení je rovněž, prostřednictvím HTML formuláře, implementována možnost nějakou kameru ze systému odstranit (smazat). Pokud je detekován požadavek na odstranění kamery (klasická obsluha HTML formuláře) tak je, kromě odstranění kamery (pomocí volání statické metody removeIPCamera třídy IPCamera), rovněž z důvodu uložení změn, volána instanční metoda saveCameras aplikačního kontroléru. V případě, že služba neběží (není vytvořena instance aplikačního kontroléru), dokáže tento servlet o této situaci odeslat hlášku (pomocí metody sendAlertNotification).
51
Java Server Pages (JSP) Součástí aplikace je i pět JSP stránek, které umožňují podávat informace o aplikaci a dále rozšiřují možnosti administrace a konfigurace systému. Konkrétně se jedná o následující stránky: •
index
•
administration
•
administration_handler
•
configuration
•
configuration_handler
JSP stránka „index“ je základní (domovskou) webovou stránkou aplikace. Dává informaci o tom, zda aplikace běží či neběží a dále nabízí odkazy vedoucí na další stránky, kde lze provést konfiguraci a spuštění systému (o to se stará dvojice stránek „administration“ a „administration_handler“), resp. odkaz na stránky, kde lze přidat novou IP kameru (účel stránek „configuration“ a „configuration_handler“). Dále je uveden odkaz na servlet RegisteredIPCameras, kde můžeme prohlížet kamery v systému registrované, resp. tyto kamery mazat.
52
6. Měření Naměřené výsledky podávají náhled na porovnání dob odezev jednotlivých akcí provedených jednak vyvinutou aplikací, jednak přímo nativním webovým rozhraním IP kamery. Měření bylo prováděno se soft-telefonem (IP Communicator) a s „klasickým, stolním“ Cisco IP telefonem. Hodnoty odezev vždy udávají dobu, za kterou došlo, po odeslání požadavku na provedení nějaké akce (tj. po stisknutí patřičného soft-tlačítka), k zobrazení obrázku již reflektujícího provedení dané akce.
Konfigurace stanice použité pro měření: Hardware: •
Notebook Acer TM 803 LMI s procesorem Pentium M 1.6Ghz, 512 MB RAM, 1 MB cache
•
Cisco Unified IP Phone 7970G
Software: •
Operační systém Windows XP s SP2
•
Apache Tomcat 6.0
•
Java Runtime Environment (JRE) 6 Update 6
•
Microsoft Internet Explorer 7.0
•
Cisco CallManager Simulator
•
Cisco IP Communicator 2.1
Výsledky měření s Cisco IP Communicator 2.1 (soft-phone)
53
Z naměřených hodnot dob odezvy je patrné poměrně velké zpoždění jak pouhé obnovy obrázku zobrazeného na displeji „soft-telefonu“, tak i doby, za kterou dojde k zobrazení obrázku již reflektujícího provedení nějaké akce (otočení objektivem, přiblížení či vzdálení snímaného objektu). Nativní webové rozhraní IP kamery přitom dává, v porovnání s naměřenými výsledky, poměrně dobré hodnoty jak odezvy aktualizace obrázku, tak i odezvy na provedení nějaké akce. Ovšem ani tyto hodnoty nejsou zcela optimální. Rovněž z nich plyne i odpovídající zpoždění „aplikace se soft-telefonem“ (ke stažení a hlavně zobrazení obrázku na displeji „soft-telefonu“ jsou třeba minimálně zhruba tři vteřiny, z čehož, při poněkud opožděnější reakci IP kamery na provedení nějaké akce, plyne i výsledné zpoždění zobrazení obrázku reflektujícího provedení dané akce). Pozn. 1) IP Communicator byl testován i na jiné, výkonnější stanici (CPU Intel Pentium 4, 3GHz, 1 GB RAM, 1MB cache, Windows XP SP2). Výsledky však byly velmi obdobné.
2) „dle nastavení“ u doby odezvy na obnovu obrázku znamená, že se jedná o konfigurovatelný parametr (v rámci administrace aplikace)
Výsledky měření s Cisco Unified IP Phone 7970G
54
Zpoždění aktualizace (stažení a zobrazení) obrázku je již výrazně nižší a odpovídá zpoždění dosahovaného nativním webovým serverem IP kamery. Doba, za kterou dojde k zobrazení obrázku již reflektujícího provedení nějaké akce (otočení objektivu, přiblížení či vzdálení snímaného objektu), je však stále poměrně dlouhá (ale menší, než tomu bylo v případě „soft-telefonu“, tedy IP Communicator-u). Ke stanovení přesné příčiny delší doby „odezvy na ovládání IP kamery“ by ovšem bylo třeba provést měření s IP kamerou, která by byla „pod naší kontrolou“. Takováto kamera bohužel nebyla k dispozici. V případě veřejně (volně) přístupných IP kamer může být zpoždění způsobeno více faktory, které však nelze přesně identifikovat (příkladem může být více uživatelů, snažících se v daný moment „ovládat“ stejnou IP kameru; nastavení aktivních síťových prvků, „za nimiž“ se kamera nachází; vlastní nastavení IP kamery, apod.). Z „logu aplikace“ (hlášek výpisových aplikací) nebyly žádné problémy vypozorovány.
55
7. Závěr Úkolem práce bylo umožnit Cisco IP telefonům ovládat IP kameru, přičemž úvodní motivací bylo vytvořit podporu pro „IP vrátného“. Předpokládalo se umístění IP kamery (podporující natáčení objektivu a přibližování, resp. oddalování snímaného objektu) v prostoru vchodových dveří do areálu nějaké společnosti. Obraz (snímky) z této kamery by se poté měly zasílat a zobrazovat na displeji Cisco IP telefonu, který by byl lokalizován například na (obecně vzdálené) recepci, kde by nemusel být počítač nebo jiný prostředek pro zobrazení obrazu z kamery. Díky této aplikaci by bylo, v jistých mezích, možné zaměstnancům recepce podat přehled o tom, kdo se chce dostat do areálu společnosti (resp. co se odehrává před vchodem do vnitřních prostor nějaké společnosti). Daného člověka by pak po ověření jeho identity bylo možné vpustit do vnitřního areálu (nějakým způsobem, touto aplikací již neřešeným). Toto ovšem nemusí být jediné nasazení této aplikace. Z názvu obou hlavních komponent systému (IP telefon, IP kamera) vyplývá využití Internet Protocol-u (IP) pro doručování dat, resp. komunikaci s jak telefonem, tak i kamerou. Potřebnou funkcionalitu (vlastní službu ovládání kamery) musí zprostředkovávat mezilehlá aplikace (middleware). Ta samozřejmě musí mít zajištěnu obousměrnou konektivitu do IP sítě. Dnes je tento požadavek uspokojen naprosto bezproblémově, jelikož (téměř) všechny operační systémy, nad kterými by mezilehlá aplikace mohla běžet, mají implementovánu podporu komunikace nad IP sítí, resp. podporu pro komunikační protokoly rodiny TCP/IP. Proto je zároveň uspokojena i potřeba komunikace nad protokolem TCP, který je transportním mechanizmem pro další protokol rodiny TCP/IP, a sice, v našem případě použitý, protokol HTTP. HTTP je využíván pro přenos aplikačních zpráv mezi jak telefonem a aplikací, tak i mezi kamerou a aplikací. Realizace komunikace nad TCP/IP protokoly je dnes standardní, široce používané řešení, a z hlediska návrhu aplikace nepředstavovalo žádný problém. Naopak díky globální dostupnosti „IP konektivity“ přináší značné výhody. Pokud totiž bude zajištěna IP konektivita mezi všemi třemi komponentami (dnes tedy téměř bez problémů), pak nejsou kladeny žádné nároky na vzájemnou proximitu jednotlivých součástí systému (telefon, kamera, aplikace). Tyto komponenty tedy mohou být lokalizovány kdekoli. Jediným omezením, ale řešitelným (například tzv. forwardováním portů či tunelováním), může být tzv. NAT (resp. PAT), tedy překlad síťových adres (a portů). Aplikace má dvě hlavní komunikační rozhraní. První je mezi aplikací a telefonem, druhé pak mezi aplikací a kamerou. Jelikož je aplikace vyvíjena speciálně pro Cisco IP telefony, které mají své, výrobcem pevně dané (proprietární), rozhraní („XML-over-HTTP“), musí jej i aplikace respektovat. Z hlediska komunikace s kamerou však již šlo volit volněji. Jediným daným protokolem, přes který musí být (vzhledem k zadání) komunikace
56
realizována je IP. Z hlediska co možná největšího odstínění konkrétních detailů a proprietárních řešení komunikačních rozhraní IP kamer různých výrobců byla zvolena metoda komunikace prostřednictvím HTTP protokolu. Navíc se zároveň jedná i o typické řešení, podporované napříč výrobci IP kamer a napříč portfoliem všech IP kamer daného výrobce. Tedy téměř každá IP kamera implementuje svůj vlastní webový (HTTP) server, který dokáže přijmout požadavky na zasílání snímků kamerou pořízených a případně i další požadavky na ovládání kamery či nějaké jiné úkony. Pro potřeby aplikace je dále vhodné využít Motion JPEG vysílání, jelikož se (Cisco IP) telefonu stejně musí zasílat individuální obrázky samostatně, tedy například MPEG vysílání dnešní Cisco IP telefony zatím zpracovat nedokáží. Třetím rozhraním aplikace je rozhraní webové, přes nějž je prováděna administrace aplikace a konfigurace IP kamer. Na toto rozhraní tedy můžeme přistoupit přes libovolný webový prohlížeč. Webové prohlížeče jsou v dnešní době naprostou samozřejmostí, navíc jsou mnohé i zdarma dostupné. Takovýto způsob administrace a konfigurace aplikace je tedy opět v souladu s dnešními standardy a zvyklostmi. Jedinou oblastí, kterou by bylo (při reálném nasazení aplikace) ještě vhodné na tomto rozhraní vylepšit, je prezentování dat (upozorňování na data), která nejsou validní. Z hlediska lepší a hlavně snadnější administrace by bylo vhodné vytvořit tzv. kaskádové styly (Cascading Style Sheets; CSS) pro odlišení nevalidních dat (samozřejmě v součinnosti s aplikací – použití „jiných“ HTML elementů pro označení nevalidních dat). Optimálně by se validace měla provádět i na straně klienta, například pomocí Java Script-u. Ale toto všechno jsou pouze „kosmetické“ detaily, které jednak nemají vliv na fungování aplikace, a jednak ani nebyly náplní této práce. Další dvě rozhraní aplikace souvisí s potřebou stálého, na chodu aplikace nezávislého, uchování informací o systémem známých IP kamerách. První podporovanou možností je ukládání do XML souboru, druhou je ukládání do MySQL databáze (obě tyto možnosti mohou být navíc i kombinovány). Opět se jedná o standardní řešení, které bylo v práci poměrně hodně diskutováno. Dalším aspektem při návrhu aplikace je bezpečnost. První problémem, který by se mohl z bezpečnostního hlediska řešit, je autorizace uživatelů. Druhou skutečností pak může být implementování podpory pro autentizaci aplikace vůči kameře, tj. poskytnutí „totožnosti (uživatelské jméno a heslo) aplikace“, která může být IP kamerou vyžadována. Dále dle možností kamery (či telefonu) realizace zabezpečeného HTTPS (HTTP-over-SSL) spojení. Bezpečnostní problematika však v rámci vyvíjené aplikace nebyla řešena, jelikož je předpokládáno nasazení buď v rámci interní sítě společnosti, kde autentizace s kamerou nebude vyžadována, nebo spojení přes Internet s volně přístupnou kamerou (nevyžadující autentizaci „příchozích“ uživatelů). Pokud by z nějakého důvodu bylo třeba vytvářet zabezpečené spojení přes veřejnou síť (Internet), může se pro tyto účely s výhodou použít 57
například technologie VPN (Virtual Private Network). V rámci interní sítě společnosti lze zabezpečení aplikace řešit na úrovni síťové infrastruktury (lze zajistit přístup pouze legitimních, autorizovaných uživatelů). Rovněž řešení a implementace bezpečnostních aspektů nebyla motivací a náplní této práce. Aplikace dovolí Cisco IP telefonům přistoupit k obrazu z IP kamery a dále, pokud to kamera podporuje, IP kameru ovládat (natáčet objektivem, přibližovat a oddalovat snímaný objekt). Zpoždění aktualizace obrázku se shoduje s původním předpokladem, tj. pohybuje se mezi jednou a dvěma vteřinami. Avšak odezva IP kamery na „ovládací požadavky“ (tj. natočení objektivu, přiblížení či oddálení) je, oproti původním předpokladům, daleko větší. Kvůli tomu může docházet k již poměrně velkému zpoždění mezi odesláním požadavku na provedení nějaké akce (například otočení objektivu) a následné odezvě kamery, resp. následnému zobrazení snímku reflektujícího provedení dané akce na displeji telefonu. Toto zpoždění může dosahovat hodnot okolo čtyř až devíti vteřin, což může být, při nasazení „v reálném čase“, neúnosné. K přesné identifikaci příčiny velikosti tohoto zpoždění by ale bylo nutné provést měření s IP kamerou, která by byla „pod naší kontrolou“. Takováto kamera bohužel nebyla k dispozici. V případě veřejně (volně) přístupných IP kamer může být zpoždění způsobeno více faktory, které však nelze přesně identifikovat (příkladem může být více uživatelů, snažících se v daný moment „ovládat“ stejnou IP kameru; nastavení aktivních síťových prvků, „za nimiž“ se kamera nachází; vlastní nastavení IP kamery, apod.). Z „logu aplikace“ (hlášek výpisových aplikací) nebyly žádné problémy vypozorovány. Rovněž i při testování veřejných IP kamer, prostřednictvím jejich nativního webového serveru, bylo toto zpoždění vyšší (v nějakých případech i poměrně velké, okolo čtyř až šesti vteřin). Nicméně bez požadavků na natáčení objektivu kamery a přibližování, resp. oddalování snímaného objektu, by použití aplikace mohlo najít své uplatnění. Jiným problémem z hlediska požadavku na možnost ovládání IP kamery je návrh a vlastní fungování Cisco IP telefonu (jeho firmware). Telefon totiž po odeslání nějakého požadavku (resp. po přístupu ke službě) a následném přijetí odpovědi tuto odpověď prezentuje uživateli na svém displeji a to tak, že původní obsah pouze překreslí tímto novým, přičemž starý si stále ponechá uložen ve své lokální paměti. K popisu tohoto problému můžeme využít analogie s balíčkem hracích karet, kdy během prezentování výsledku získaného od služby obsluhující zaslaný požadavek, dojde k překrytí původního obsahu displeje (vrchní karty balíčku karet) obsahem novým (novou vrchní kartou). Dochází tedy vlastně k překrývání původního obsahu „novou kartou“. Po stisku „soft-tlačítka“ Exit telefon „vrchní kartu odebere a zobrazí kartu bezprostředně pod ní ležící“. Tato skutečnost působí problémy při odesílání požadavků na například otočení objektivu kamery (nebo i libovolného jiného požadavku, kromě prostého požadavku na „aktualizaci displeje“). Po odeslání tohoto požadavku telefon čeká na odpověď, kterou je, přirozeně, stále získání aktuálního obrázku
58
z IP kamery (vlastní otočení se odehrává „na pozadí“). Tento nový aktuální obrázek poté ale telefon zobrazí jako „novou vrchní kartu“, čili nedojde k pouhé a očekávané aktualizaci „vrchní karty“, takže po stisknutí tlačítka „Exit“ nedojde k očekávanému opuštění služby (ukončení sledování dané IP kamery a návratu do původního menu), ale k pouze odebrání „vrchní karty a zobrazení té pod ní ležící“. Při větším počtu zaslaných ovládacích požadavků může být návrat do předpokládaného kontextu (opuštění služby sledovaní IP kamery) poměrně zdlouhavý a matoucí. Řešením této situace je (může být) užití tlačítka „Services“, které povede ke „kompletnímu opuštění služeb“ a návratu do základního (výchozího) menu (stavu) telefonu. Pokud ovšem nejsou požadavky na ovládání (natáčení objektivu, přibližování či oddalování), tak dochází pouze ke skutečnému (předpokládanému) aktualizování displeje (tedy k „překreslení vrchní karty“). To díky podpoře „HTML meta refresh funkcionality“, tedy instruování telefonu (webového prohlížeče) ke znovunačtení obsahu (webové stránky), dle reference (URL) předané právě pomocí „meta refresh“ elementu. Výše zmíněný problém je dán návrhem a realizací Cisco IP telefonu a z hlediska aplikace jej nelze nijak řešit. Tyto skutečnosti opět působí jisté problémy při „ovládání kamery“, ale služby pouhého zobrazování snímku se nedotýkají. Dalším problémem, rovněž souvisejícím s vlastním fungováním Cisco IP telefonu (s jeho firmwarem), je způsob překreslování (aktualizace) displeje telefonu. Na displeji telefonu jsou, současně s obrázkem z IP kamery, zobrazena i „soft-tlačítka“, která jsou namapována na ovládání kamery (tj. tlačítka pro akce jako je otáčení objektivu, apod.). Ta jsou během aktualizace obrázku (displeje telefonu) překreslována rovněž. Při rychlé aktualizaci displeje (faktor nastavitelný v rámci konfigurace aplikace) tedy dochází k velmi nepříjemné situaci, kdy uživatel vlastně ztrácí možnost (rozumného či pohodlného) ovládání kamery, jelikož právě ovládací tlačítka jsou neustále překreslována, tedy efektivně jsou nedostupná. Situaci lze řešit pouze tak, že se během aktualizace displeje stiskne „soft-tlačítko“ Cancel, jehož zobrazení během znovu-načítaní obsahu displeje je dáno firmwarem telefonu. Provedení této akce má za následek přerušení aktualizace displeje (stahování nového obrázku) a zobrazení původního obsahu, tedy posledního dostupného obrázku společně s právě ovládacími tlačítky, přičemž k automatickému obnovování displeje již nedochází. Potřebnou akci tedy lze komfortně provést, avšak za cenu toho, že nedochází k aktualizaci obrázků (v době před následným stisknutím daného „soft-tlačítka“ pro provedení požadované akce). Přes tyto všechny výše prezentované problémy lze aplikaci použít pro zobrazování snímků získaných prostřednictvím IP kamery na displeji Cisco IP telefonu. Při ústupu od požadavků na dostatečně rychlou odezvu (zobrazování „chtěných“, tedy v danou chvíli skutečně aktuálních, snímků) pak lze aplikaci použít i k ovládání IP kamery, tj. pro natáčení objektivu a přibližování, resp. oddalování objektu IP kamerou snímaného. Aplikace přitom dovolí více telefonům přistupovat k jedné nebo i více kamerám „současně“ (tj. dovolí
59
probíhání více souběžných relací „telefon-kamera“). Aplikace tedy splňuje všechny podmínky zadání. Vytváření této aplikace bylo poměrně zajímavé. Během vývoje aplikace se navíc „zabrousilo“ do poměrně mnoha různých oblastí, což bylo velmi přínosné a zajímavé.
60
Použitá literatura a zdroje [1]
Darrick Dell, Mark Nelson, Anne Smith, Developing Cisco IP Phone Services, Cisco Press, 2002, ISBN 1-58705-060-9
[2]
Webové stránky společnosti Cisco Systems – http://www.cisco.com/ • Cisco Documentation, CiscoIPPhone XML Objects http://www.cisco.com/univercd/cc/td/doc/product/voice/vpdd/cdd/5_0/5_0_1/ipphsv/ip503ch2.htm
[3]
Webové stránky společnosti Axis Communications – http://www.axis.com/
[4]
Apache Tomcat, http://tomcat.apache.org/
[5]
Grafické formáty I – JPEG a PNG, Nikola Čech, eMag.cz, 25. ledna 2007 •
[6]
Portable Network Graphics, W3C (World Wide Web Consortium) •
[7]
http://www.kosek.cz/clanky/cw/png.html
Formát PNG – podívejme se na něj podrobněji, Libor Kyncl, 28. září 2002 •
[9]
http://www.w3.org/Graphics/PNG/
PNG – nový grafický formát nejen pro Web, Jiří Kosek ml., 1999 •
[8]
http://www.emag.cz/graficke-formaty-i-jpeg-a-png/
http://web.net-mag.cz/?action=art&num=220
Jakarta Tomcat, Bohdan Čech •
http://www.fi.muni.cz/~kas/p090/referaty/2003-jaro/skupina10/tomcat.html
[ 10 ] Apache Tomcat – konfigurace, srovnání s jinými servery, David Měrka, podzim 2005 •
http://nb.vse.cz/~zelenyj/it380/eseje/xmerd04/Tomcat.htm
[ 11 ] Java a MySQL, PC svět, Michal Zbortek, 2003 •
http://www.pcsvet.cz/art/article.php?id=3351
[ 12 ] Data do databáze nebo do XML, Tomáš Kouba, 23. května 2004 •
http://www.neo.cz/~tomas/java.net/2004/05/data-do-databze-nebo-do-xml.html
[ 13 ] Java Class.forName(String className) and JDBC, Aaron Johnson, 31. července 2005 •
http://cephas.net/blog/2005/07/31/java-classfornamestring-classname-and-jdbc/
[ 14 ] Wikipedia – http://www.wikipedia.org/, http://cs.wikipedia.org/wiki/Hlavn%C3%AD_strana •
IP Phone, http://en.wikipedia.org/wiki/IP_phone
•
IP telefon, http://cs.wikipedia.org/wiki/IP_telefon
•
JPEG, http://en.wikipedia.org/wiki/JPEG
•
JPEG, http://cs.wikipedia.org/wiki/JPEG
•
The JPEG Committee home page, http://www.jpeg.org/
•
Motion JPEG, http://en.wikipedia.org/wiki/MJPEG
•
Video compression, http://en.wikipedia.org/wiki/Video_compression
•
Java Bean, http://cs.wikipedia.org/wiki/Java_Bean
61
•
Java Database Connectivity, http://en.wikipedia.org/wiki/JDBC
•
Java Database Connectivity, http://cs.wikipedia.org/wiki/Java_Database_Connectivity
•
JDBC driver, http://en.wikipedia.org/wiki/JDBC_driver
•
Open Database Connectivity, http://en.wikipedia.org/wiki/Open_database_connectivity
IP kamery [1]
Axis 213 PTZ Network Camera – http://www.axis.com/products/cam_213/index.htm
[2]
Veřejně přístupná Axis 213 PTZ IP kamera (Live view), Skiathos Islands Municipality, Řecko, http://84.205.233.40/view/index.shtml
[3]
Další veřejně přístupné Axis IP kamery, Axis Demo Gallery, http://www.axis.com/solutions/video/gallery.htm
Cisco Unified Communications [1]
Cisco IP Communicator 2.1, datasheet •
[2]
http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/phones/ps5475/product_data_she et09186a00801f8e48.html
Cisco Unified IP Phone 7975G • http://www.cisco.com/en/US/products/ps8538/index.html
62
Příloha 1. Speciální značkovací sekvence používané formátem JPEG
Obr. 48 – Speciální značkovací sekvence používané formátem JPEG (zdroj: http://en.wikipedia.org/wiki/JPEG)
2. Veřejně přístupné IP kamery Axis 213 PTZ Network Camera (Live view) •
Řecko, volně přístupné a volně ovladatelné AXIS 213 PTZ IP kamery Skiathos Islands Municipality http://84.205.233.40/view/index.shtml – webové rozhraní IP kamer http://84.205.233.40/mjpg/video.mjpg – přímý odkaz na Motion JPEG vysílání (stream)
63
•
Švýcarsko, volně přístupné a volně ovladatelné AXIS 213 PTZ IP kamery Domaine Blondel Chemin du Vigny 12 1096 Cully/Lavaux Suisse http://www.domaine-blondel.ch/ http://217.114.115.192/view/index.shtml – webové rozhraní IP kamery (s možností volby konkrétní kamery) http://217.114.115.192/mjpg/video.mjpg – přímý odkaz na Motion JPEG vysílání (stream) jedné z kamer
•
Nizozemsko, volně přístupné a volně ovladatelné AXIS 213 PTZ IP kamery Koudum http://www.koudum.nl/ http://www.koudum.nl/webcam/ – webové rozhraní IP kamery (s možností volby konkrétní kamery) http://195.73.15.148:82/view/view.shtml – webové rozhraní IP kamery (s možností volby konkrétní kamery) http://195.73.15.148:82/mjpg/video.mjpg – přímý odkaz na Motion JPEG vysílání (stream) jedné z kamer
Axis 214 PTZ Network Camera (Live view) •
Finsko (nejspíše) Bohužel, tato IP kamera není volně (anonymně) ovladatelná. http://213.28.44.184/view/index.shtml – webové rozhraní IP kamery http://213.28.44.184/mjpg/video.mjpg – přímý odkaz na Motion JPEG vysílání (stream) kamery
Sony Network Camera SNC-RZ30 Jedná se o IP kameru se statickým objektivem. http://24.39.88.218/index.html – webové rozhraní IP kamery http://24.39.88.218/image?speed=0 – přímý odkaz na Motion JPEG vysílání (stream) kamery
Sony Network Camera SNC-CS10 Jedná se o IP kameru se statickým objektivem. http://194.177.250.229/ – webové rozhraní IP kamery http://24.39.88.218/image?speed=0 – přímý odkaz na Motion JPEG vysílání (stream) kamery
Panasonic Network Camera BL-C10A Jedná se o IP kameru se statickým objektivem. http://65.254.62.79/CgiStart?page=Single&Language=0 – webové rozhraní IP kamery http://65.254.62.79/cgi-bin/nphContinuousServerPush?Resolution=320x240&Quality=Clarity – přímý odkaz na Motion JPEG vysílání (stream) kamery
64
3. Přehled XML objektů podporovaných Cisco IP telefony Přehled XML objektů byl převzat z dokumentu CiscoIPPhone XML Object Quick Reference, který je dostupný na veřejně přístupných webových stránkách společnosti Cisco Systems.
65
66
(zdroj: http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/all_models/xsi/6_0/english/programming/guide/xsi60xml.pdf)
XML Schema File (CiscoIPPhone.xsd), vážící se k výše prezentovaným XML objektům, lze rovněž stáhnout z veřejně přístupných webových stránek společnosti Cisco Systems. Konkrétně se jedná o dokument Cisco Unified IP Phone Services XML Schema File. (viz http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/all_models/xsi/5_0_2/english/programming/guide/ip502apb.pdf)
67
4. Obsah přiloženého CD readme.txt index.html index.css text/ dip.pdf
– textový soubor s popisem obsahu CD – popis obsahu CD ve formátu HTML – CSS pro index.html – adresář obsahující vlastní text práce – text diplomové práce ve formátu pdf
src/
– adresář se zdrojovým kódem aplikace CiscoIPPhoneIPCameraService.zip – projekt aplikace CiscoIPPhoneIPCameraService vytvořený ve vývojovém prostředí NetBeans 6.0 src.zip – zdrojové soubory aplikace ipcameras.xml – vstupní XML soubor s IP kamerami popis_programu.txt – textový soubor s popisem programu
etc/
– adresář s ostatními aplikacemi/utilitami apache-tomcat-6.0.16.zip – Apache Tomcat (6.0.16) apache-tomcat-6.0.16.exe – Apache Tomcat Installer (6.0.16) apache-ant-1.7.0-bin.zip – Apache Ant (1.7.0) mysql-connector-java-5.1.6-bin.jar – MySQL Java Connector (5.1.6)
68
