elméleti áttekintés

Web adatbázis programozás

Horváth Győző, Menyhárt László, Papp Szabolcs, Tarcsi Ádám2009. szeptember. 10.

Elméleti áttekintés

Bevezetés, témafelvetés, előzmények

Hálózati, szerver és kliens oldali megoldások (TCP/IP és HTTP protokoll és működése) Számítógépes hálózatok

WEB-es prezentációs megoldások (HTML nyelv, CSS), web-grafika Web-fejlesztés I. (HTML speci) és Web-szerkesztés

WEB szerverek, böngészők, kliens oldali WEB programozás alapjai (pl. JavaScript) Web-fejlesztés II., Web-programozás I.

Adatbázis-kezelés (a relációs modell, adatmodellezés, SQL) Adatbázis-kezelés Rendszerek közti adatkommunikáció „önleíró” dokumentum nyelven = XML (XML

felépítése, használata, kapcsolódó technológiák érintőlegesen: DTD, XSD, XSL ill. XSLT) Adatkezelés – XML és Web adatbázis programozás

XML alapú adatbázisok (XML adattárolás alapjai, lekérdező nyelvek: XPath, XQuery) Adatkezelés – XML és Web adatbázis programozás

Multimédiás adatbázisok (nagy méretű multimédiás anyagok tárolása adatbázisokban, visszakeresés, hatékonyság) Web adatbázis programozás

Programozási módszertan Programozás tárgyak WEB programozás (módszerek, beágyazott script-nyelvek általában, PHP részletesen)

Web-fejlesztés II, Web-programozás I. Vállalati környezetre tervezett webes fejlesztői környezetek (pl.: .Net, Java)

Web-programozás II, Programozási nyelvek (Java), Elosztott alkalmazások készítése, Java alkalmazások, Java

2

Bevezetés, témafelvetés, előzmények

Multimédiás WEB programozás – bináris tartalmak (stream-ek, header, letöltés, feltöltés) Web adatbázis programozás

Multimédiás WEB programozás – vektorgrafikus és programozott tartalmak (SVG, Flash) Web-animáció és Web adatbázis programozás

Informatikai biztonság (adatvédelem, kommunikációs vonalak védelme, védelem illetéktelen behatolásokkal szemben, meghibásodások elleni védelem) Számítógépes hálózatok, Web adatbázis programozás

Többrétegű (összetett) webes alkalmazások fejlesztése Web adatbázis programozás

3

4

Architektúrák – „Evolúció”

Egygépes (standalone) alkalmazások

A program teljes egészében a munkaállomáson fut.

Az adatok ugyanitt tárolódnak. Egyszerre csak egy felhasználó használhatja. Semmilyen hálózati kapcsolat nincs, a különálló

programok közti adatszinkronizáció meglehetősen nehézkes.

5

K liens gép 1

Program

Adatok (fájlok)

K liens gép 2

Program

Adatok (fájlok)

K liens gép N

Program

Adatok (fájlok)

...

• Egy vagy több szerver gép erőforrásait (jellemzően adatait) megosztja a kliensek között. Jobb esetben on-line. • Az alkalmazás egy része (adatbázis-kezelő rsz.) a szerven fut. • Az alkalmazás logikát implementáló rész a kliens gépeken fut. „vastag kliens rendszerek” • Egy adatbázist többféle kliens program is használhat. • Egyszerre több konkurrens felhasználó használhatja. 6

Egyszerű kliens-szerver alkalmazások 1.

S zerver gép

K liens gép 1

Program

K liens gép 2

Program

K liens gép N

Program

...

Intranet

RDBMS (RelationalDataBase Managem ent

System )

• Jellemzően intranet-es alkalmazásoknál használatos.• Terheli a kliens gép erőforrásait.• Gyakran mindenféle driver-ek telepítését igényli a kliens gépeken• Verziófrissítés alkalmával az összes kliens-en frissíteni kell a programot. • A RAD (Rapid Application Development) sok eszközzel támogatott, számos jó vizuális fejlesztőkörnyezet: gyorsan „összekattint-gathatunk” és leprogramozhatunk komoly alkalmazásokat.

7

Egyszerű kliens-szerver alkalmazások 2.

S zerver gép

K liens gép 1

Program

K liens gép 2

Program

K liens gép N

Program

...

Intranet

RDBMS (RelationalDataBase Managem ent

System )

Többrétegű (multitier) hálózati alkalmazások

Minimálisan három réteg létezik: ▪ Front End = kliens oldali felhasználói réteg

(általában egy WEB böngészőben) ▪ Middleware = szerver oldali prezentációs és

logikai réteg (általában egy WEB szerveren beágyazott script-ekben összeolvasztva a megjelenítés és az egyszerűbb logika)

▪ Back End = hátsó szerver oldali nagykapacitású tároló (adatbázis szerver) vagy számoló réteg

8

Háromrétegű architektúra

9

B ack E ndM idd lewareFront E nd

W eb szerver

K liens gép 1

W EB Böngésző

K liens gép 2

W EB Böngésző

K liens gép N

W EB Böngésző

...

Internet/Intranet

A datbázis szerver

RDBMS (RelationalDataBase Managem ent

System )

W eb Server

ApplicationServer (pl. PHP)

A datbázis szerver

XML DBMS (XMLDataBase Managem ent

System )

E gyéb szerver

Nagykapacitású,bonyolul

szám ításokat végzőalkalm azás

Többrétegű architektúra

10

M idd leware

P rezentációslayer

B ack E ndFront E nd

W eb szerver1

K liens gép 1

W EB Böngésző

K liens gép 2

W EB Böngésző

K liens gép N

W EB Böngésző

...

Internet/Intranet

A datbázis szerver

RDBMS (RelationalDataBase Managem ent

System )

A datbázis szerver

XML DBMS (XMLDataBase Managem ent

System )

E gyéb szerver

Nagykapacitású,bonyolul

szám ításokat végzőalkalm azás

W eb Server

Prezentációsalkalm azás (pl.

JSP)

W eb szerverK

W eb Server

Prezentációsalkalm azás (pl.

JSP)

...

Logika i layer

A pp likációsszerver1

ApplicationServer

...A pplikációs

szerverM

ApplicationServer

Többrétegű architektúra jellemzői

Load balancing, terhelésmegosztás. Tervezést támogató környezetek: Java

J2EE, .Net. Architektúra felosztás-összevonás logikai

szinten. A rendszer logikai architektúrája (tervezés,

programozás) független a számítógépes megvalósítástól, hálózattól.

A logikai réteg tovább osztható. Nagyon sok konkurens felhasználó

kiszolgálására optimalizálva11

Többrétegű architektúra jellemzői

Kliens gép: böngésző, a logika – többnyire – a szerveren található – vékony kliens architektúra

Minimális logika a klienseken: a beviteli adatok validálására, a lapok speciális megjelenítésére (pl. JavaScript).

A szerveren elkülönül az adattárolás, a logika és a prezentáció eltérő szerepkörök

Az egyes szintek önmagukban is tesztelhetőek. A rendszer egyes komponensei több célra vagy

újra felhasználhatók.

12

Többrétegű architektúra jellemzői

A vékony kliensek miatt nagyon gyenge kliens gépek is elegendők.

A technológia platformfüggetlen. A kliensekre nem kell drivert telepíteni. A verziófrissítés csak a szervert érinti, a klienseket

nem. Sajnos egyelőre elég kevés eszköz támogatja a RAD-

ot (Rapid Application Development), a környezet kevés segítséget nyújt a programozónak a megoldási lehetőségek kiválasztásában▪ „Házi szabványok”, saját keretrendszerek készülnek.

Nehezebb tesztelni

13

14

Fejlesztői - megrendelői „evolúció”

Fejlesztői evolúció 1. szint – Kezdeti

▪ Fejlesztő oldaláról· Legtöbb web programozó, HTML-t "írók".· Statikus web lapok· WYSIWG szerkesztők, szövegszerkesztők· Nem használnak mintákat, sablonokat· Nem használnak fejlesztést segítő eszközöket· Tesztelés hiányzik vagy kezdetleges· Nem jellemző a program logika· Kis csapat, kezdetleges oldalak· Nincsenek elkülönült szerepek

▪ Megrendelő szempontjából· Elsődleges cél a jelenlét az Interneten· Kevés, ritkán változó tartalom· Csak egy ún. elektronikus prospektus oldalt várnak el· Kevés visszatérő látogató (ha van egyáltalán)· Nincs web-es stratégia, vagy cél

15

Fejlesztői evolúció 2. szint – Ismételhető

▪ Fejlesztői oldalról· A hagyományos web programozást segítő tananyagok,

könyvek segítségével ezt a szintet lehet elérni· Tapasztalat útján, sok megrendelést követően juthat el

ide a cég a fejlesztő cég mérete növekedik· Elkezdenek újrafelhasználható komponenseket,

sablonokat használni· Dinamikus weblapok megjelenése, kezdetleges program

logikábal. A növekvő megrendelési igények miatt is· Típus hiba: kísérletező fejlesztő, a legújabb

technológiákat használja a "szép oldalakért", de a funkcionalitás rovására.

▪ Megrendelő szempontjából· A megrendelő is fejlődik, a tartalom frissessége is számít

már.· A megrendelő szeretné a tartalmat maga alakítani

16

Fejlesztői evolúció 3. szint - Meghatározott

▪ Megrendelő szempontjából· A marketing stratégia és a web stratégia összetalálkozik· Konkretizálódnak az elvárások· Vevőkkel, partnerekkel is elektronikusan akarják tartani a

kapcsolatot· Intranet oldalak megjelenése

▪ Fejlesztő oldaláról· E-kereskedelmi, ügyfélszolgálati szolgáltatások

megjelenése· Profi fejlesztő csapat szükséges· Használnak már fejlesztő, tervező eszközöket.· Biztonsági elvárások is megjelennek· Folyamatos fejlesztői képzések· Adatbázisok használata· A fejlesztői szerepek szétválnak: programozó, adatbázis

és (web) server adminisztrátor, designer

17

Fejlesztői evolúció 4. szint – Menedzselt

▪ Megrendelő szempontjából· Tartalomkezelő rendszer használata szükséges· Belső portál az alkalmazottaknak és a partnereknek· Profi belső üzemeltetői csapat is kellhet (nem minden

esetben!)▪ Fejlesztői oldalról

· Web service – Szolgáltatás Orientált Architektúra· Architektúra tervezés· Alapvető Web 2.0 alkalmazások megjelenése· Projektmenedzsment a középpontba kerül· Munkafolyamat-kezelés· Célok, eredmények mérése, értékelése· További szintek: tervező, rendszerszervező, tesztelő· Állandó együttműködés a megrendelővel· Menedzselhető fejlesztő rendszerek: J2EE, .NET.

18

Fejlesztői evolúció 5. szint – Optimalizáló

▪ Megrendelő oldaláról· ERP funkciók az Intraneten,· Az elkülönült IT rendszerek összeköttetése,· A piac gyors, rugalmas reakciókat vár el

▪ Fejlesztő oldaláról· A szervezet fejlődik, alkalmazkodik, tanul!· A fejlesztői folyamatok folytonos változása a

legfontosabb.· Produktivitás, hatékonyság, a megrendelői elvárások

kerülnek a középpontba.· Hiba megelőző, elemző módszerek a fejlesztésben.· A termék a lehető legjobb minőségben készül el,

határidőre!

19

20

Egyéb területek

Internetes alkalmazások korlátai

Kliens erőforrásainak elérhetősége Kliensek különbözőségének kezelése Sávszélesség problémák Számítás-igényes alkalmazások nehézségei

21

Multimédiás adatbázisok

Kurrens terület, ahol a web-es környezet le van maradva Kliens oldali nehézségek: A böngészőn esetleg speciális plug-in

szükséges a tartalom megjelenítéséhez. Prezentációs és logikai szint: A tartalmakat nem tudjuk

egyszerűen változókba tölteni, mint elemi típusok esetén, hanem stream-ekkel kell dolgozni. Ennek a technikáját meg kell ismerni. A HTTP protokoll ismerete is szükséges, hagyományos dinamikus WEB oldalakat általában a környezet default beállításaival le tudunk küldeni a kliens-re, míg multimédiás tartalom esetén a HTTP header-t módosítani kell.

Adatbázis: A nagyméretű bináris adatok tárolása pl. relációs adatbázisokban; valamint a visszakeresés, módosítás egy külön nagy kutatási területet jelent az adatbázisokkal foglalkozó ágon belül. Ez korrelál bizonyos mesterséges intelligenciabeli módszerekkel is.

22

XML

<nev>Gipsz Jakab</nev> XML mint tárolás: SVG, MPEG7 Kommunikáció

▪ Értelmezhető▪ Platform-független

Adat és megjelenés elválasztása XML (hierarchikus) adatbázisok vs. relációs

modell

23

Miért PHP? Pro és kontra

PRO Web-programozás I, PHP speci, mint alap. Elterjedt: az Apache WEB szerverrel együtt nagyon

hatékony, ténylegesen képes akár több ezer konkurrens (párhuzamosan beérkező) kérést kiszolgálni.

Egyszerű megtanulni. Példáink más nyelveken, környezetben is működnek.KONTRA Nehéz a funkciók (prezentáció és logika)

szétválaszthatósága a környezet nem segíti. A team munkát sem támogatja. Egyes feladatok könnyebben, szebben, jobban

megoldhatóak egy erősebb fejlesztői környezetben pl.: Java, .NET

24

Irodalomjegyzék

Frigó József: Többrétegű architektúrák.BME, 2000-2006http://www.inf.bme.hu/~frigo/ooret7/tiers.odp

Martin Fowler: Analysis Patterns - Reusable Object Models. Addison-Wesley, 1997

Papp Szabolcs: Bevezető jegyzet a Web-adatbázis programozás c. tárgyhoz.ELTE Informatikai Kar, 2005.

Tarcsi Ádám: Quality measurement of Business WEB Applications.Serdica Journal of Computing, 2008.

25