Témakörök ● Milyen alkalmazásoknál lehet erre szükség? ● Rossz megoldások (közvetlen adatbázis kapcsolat, statikus tartalmak) ● XML ● Web services ● SOAP, WSDL ● RSS ● REST ● JSON ● Push notification
Mikor? Milyen alkalmazásnál? ● Ha távoli adatokat kell elérjünk: ● 1. Példa: egy hírportálhoz készült mobil alkalmazás: ● El kell érjük a hírek listáját a webes formázások nélkül ● Keresni, rendezni, szűrni kell tudjunk ● 2. Példa: egy ingatlan közvetítő alkalmazás: ● Komplex keresési feladatok, találatok betöltése, lapozás a találatok között ● Kapcsolatfelvétel, üzenet küldés ● Titkos információk védelme (az ingatlan pontos címe, tulajdonos adatai) ● Ha adatokat szeretnénk eltárolni úgy, hogy azt más készüléken is elérhessük: ● Felhő megoldások, biztonsági másolatok ● Üzenetküldés: ● Ha két felhasználó akar egymással üzenetet váltani, egymásnak üzenetet küldeni.
Rossz megoldások ● Közvetlen kapcsolat az adatbázis szerverhez: ○ A kapcsolódási adatokat az alkalmazásba kellene “beégetni”, ami könnyen kinyerhető mások számára ○ A hozzáférési adatok birtokában más adatokhoz is hozzáférhetünk ● HTML tartalmak parse-olása: ○ Nem kell külön adatforrás, majd a weblap adatait feldolgozzuk, átstruktúráljuk ■ egy apróbb design módosítás is működésképtelenné teheti az alkalmazást
Stateful vs. Stateless ● Stateful: egy munkamenet azonosítóval azonosítja a klienst a szerver ○ Előnye: nem kell minden kérésben minden adatot elküldeni (pl. bejelentkezési adatok, keresési, szűrési feltételek) ○ Hátránya: a munkamenet inaktivitás után lejár, a munkamenet azonosító megszerzésével megszemélyesíthetjük a felhasználót. ○ Mobil alkalmazásoknál ritkán használjuk
Stateful vs. Stateless ● Stateless: a szerver nem tárol el a korábbi tranzakcióinkból semmilyen adatot, minden tranzakcióban minden adatot meg kell adni. ○ Előnye: nem kell külön erőforrást fordítani a munkamenet kezelésére, életben tartására ○ Hátránya: Minden üzenetben meg kell adnunk minden adatot (pl. bejelentkezési adatok), ez növeli az üzenetek méretét
XML ● EXtensible Markup Language ● A legtöbb adatcsere formátum közös jellemzője, hogy XML struktúrát használ ● Miért szeretjük az XML-t? ○ Szöveges állomány, ember számára is olvasható, értelmezhető ○ Gyakorlatilag minden platformon van támogatás a feldolgozásukra, generálásukra ○ Fejlett validálási megoldások (DTD, XSD)
Web services ● Alkalmazások közötti adatcsere szabványok és protokollok gyüjteménye ● A célja, hogy két különböző szoftver (pl. java és egy c++ program) egymással kommunikálni tudjon. ● Példa 1: egy autó alkatrész értékesítő országos hálózat Rendelkezik egy webáruházzal és telepíthető Windows alatti futó alkalmazással. A desktop alkalmazás SOAP protokollon keresztül éri el a központi adatbázist.
SOAP, WSDL ● SOAP - Simple Object Access Protocol ● Széles körben elterjedt adatcsere protokoll ● Példa: MNB valuta árfolyam lekérdezése SOAP segítségével: Részletes leírás: www.mnb.hu/arfolyamok.asmx
WSDL: Webszolgáltatás leíró nyelv, ebben leírhatjuk, hogy milyen metódusokat tudunk SOAP-on keresztül meghívni, azoknak milyen paraméterei és visszatérési értékei vannak. Használata nem kötelező.
●
SOAP mobil környezetben A protokoll tökéletesen alkalmas lenne mobil
alkalmazásokhoz, de sajnos a natív SDK szinte egyik platform esetén sem támogatja. ● 3rd party library-k léteznek android és iOS platformra is, de ezek működése sajnos nem mondható tökéletesnek. ● Ezen okok sajnos azt eredményezik, hogy egy új projekt esetén nem javasolt SOAP-ra építeni a rendszert. ● Meglévő SOAP-os infrastruktúra esetén érdemes csak ebben gondolkodni
RSS ● Rich Site Summary ● Arra feljesztették ki, hogy a gyakram frissülő site-ok az új tartalmak rövid összefoglalójának terjesztésére. ● Ez alkalmas lehet egy mobil hírolvasó alkalmazás vagy widget működéséhez. Példa: <![CDATA[ Amikor még aranyból voltak a Földközi-tenger szigetei ]]> http://index.hu/mindekozben/poszt/2014/08/25/amikor_meg_aranybol_voltak_a_foldkozi-tenger_szigetei/
REST ● Representational State Transfer ● Megszorítások: ○ kliens-szerver architektúra: a kliensek nem foglalkoznak adattárolással, a szerverek nem foglalkoznak felhasználói felülettel ○ állapotmentes: a szerver nem tárolja a kliens állapotát, minden kérés minden információt tartalmaz ○ gyorsítótárazhatóság: minden kérésnek tartalmaznia kell, hogy gyorsítótárazható-e ○ réteges felépítés: lehetőséget ad arra, hogy közvetítőn keresztül kapcsolódjunk a szolgálatatáshoz ○ egységes interfész ○ igényelt kód (opcionális): a szerverek képesek lehetnek a kliens funkcióinak kiterjesztésére program részletek átadásával, amit a kliens futtatni tud
JSON ● JavaScript Object Notation ● Kis méretű, szöveges, ember által olvasható adatcsere formátum ● Az XML-nél tömörebb, kevesebb adatforgalmat igényel ● Támogatott adattípusok: ○ szám (double) ○ karakterlánc ○ bool ○ tömb ○ objektum ○ null
JSON ● Használata: ○ Javascript AJAX ○ Mobil alkalmazások és webszerverek közötti adatcsere ● Mobil alkalmazások: ○ iOS, Android, Windows Phone SDK-ban egyszerűen feldolgozható és generálható JSON tartalom. ○ HTTP POST kérésben elküldjük a kérést a szerver felé ○ A válaszban visszakapjuk a kért eredményt
Push Notification ● A mobil készülék életben tart egy TCP kapcsolatot, amire a szerver értesítéseket tud küldeni. ● Android esetén Google Clound Messaging (GCM) néven érhető el ● iOS esetén Apple Push Notification Service (APNs) ● Ha értesítést szeretnénk küldeni, akkor a Notification server felé kell elküldenünk az alkalmazás azonosítóját, a felhasználó azonosítóját és az üzenetet. ● A mobil készülék az alkalmazás azonosító alapján dönti el, hogy melyik alkalmazásnak szól és engedélyezett-e az értesítés.
Biztonság ● HTTPS feletti kommunikáció ● Forráskódba beégetett jelszavak használatának mellőzése ● Szerver oldalon a jogosultságok ellenőrzése minden műveletnél ● A szerver megszemélyesítésével járó támadásra való felkészítés: a támadó eléri, hogy az ő szervere válaszoljon az alkalmazás kérésére. Megoldás: a bizalmas üzenetek nyilvános kulccsal történő aláírása és az aláírt üzenethez egy véletlen sorozatot is fűzzünk a visszajátszás megakadályozása érdekében
Példa alkalmazás A mobil alkalmazásból a felhasználó tud fiókot regisztrálni és bejelentkezni. A fiókot a saját szerverünkön tároljuk és a bejelentkezést is mi végezzük. 1. lépés: adatbázis tábla létrehozása: CREATE TABLE `users` ( `username` varchar(20) NOT NULL , `password` varchar(16) NOT NULL , `email` varchar(25) NOT NULL , PRIMARY KEY (`username`) )
Példa alkalmazás 2. JSON üzenetek definiálása: Regisztráció:
