RESTful web-szolgáltatások készítése WCF-ben

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "RESTful web-szolgáltatások készítése WCF-ben"

Átírás

1 Szegedi Tudományegyetem Informatikai Tanszékcsoport Diplomamunka Készítette: Pótári Tamás Programtervező informatikus MSc Témavezető: Dr. Alexin Zoltán Egyetemi adjunktus Szeged 2011

2 Feladatkiírás Napjaink kisvállalkozásai a kereskedelmi szférában egy webshop-pal, illetve egy ettől független vagy szerencsésebb esetben ezzel összhangban lévő számlázó és raktárkészlet nyilvántartó alkalmazással kezdik tevékenységüket az internet nyújtotta végtelen piacon. Idővel viszont a rendelkezésre álló informatikai megoldás kevésnek bizonyul számukra. Így szükségük lesz egy komolyabb kereskedelmi rendszerre, mellyel bővíthetik lehetőségeiket a mindennapi versenyben. Erre a problémára az ERP-k nyújtanak megoldást, melyekből rengeteg található a piacon. A diplomamunkám egy tipikus problémakörre koncentrál, ami legtöbbször egy ERP bevezetése előtt, vagy éppen bevezetés közben szokott jelentkezni. A valamirevaló ERP-k rendelkeznek webes felülettel, hétköznapian fogalmazva: webshop-pal. De megeshet, hogy ez a webshop nem elégíti ki a megrendelők igényeit, ezért át szeretnék azt alakíttatni az ERP szállítójával. Sőt felmerülhetnek olyan igények is, hogy az új ERP rendszert összekössék a bevált, vásárlók számára jól ismert, korábbi webshop-jukkal. Az összekapcsolás rendkívül kényes kérdés. Miután tisztázták a felek a két (vagy több) rendszer kommunikációjának sarokpontjait, irányát, gondoskodniuk kell a technológiai akadályokról is. A két rendszer ugyanis nagy valószínűséggel egymástól teljesen eltérő platformon működik, így a fejlesztők kommunikációja is nehézkes. De mégis egy elvi kérdés a legnyugtalanítóbb, miszerint egy ERP szállító, a termékük adatbázisát és üzleti logikai rétegét nem szívesen teszi közzé egy másik cég számára. A megoldás egy API. Diplomamunkám célja egy meglévő és működő, webes kereskedelmi rendszer kibővítése web-szolgáltatásokkal az imént említett API megvalósítása érdekében. Így könnyedén össze lehet kötni más rendszerekkel, a korábban említett problémákat áthidalva. Mivel a kereskedelmi rendszer Microsoft.NET alapú, ezért a WCF technológiával implementálom az API-t, mint RESTful szolgáltatások halmaza. Bemutatom a szóban forgó kereskedelmi rendszer főbb szolgáltatásait. Részletekbe menően szemléltetem a modellezés, az implementálás, a beüzemelés és a tesztelés minden lépését. A fejlesztési folyamat rendkívül széles technológiai látókört igényel; a REST világ, a Microsoft WCF, a Microsoft SQL Server, IIS7 és a.net komponensorientált programozás, csakhogy néhány témakört említsek. Ezek legtöbbjét, szükségszerűen be is mutatom, sőt elismert fejlesztők és szakértők tervezési módszereit, technikáit alkalmazom. Betekintést biztosítok a REST és RESTful világba majd a WCF érintett szegmensébe. 2

3 Az elkészített web-szolgáltatásokat akár más szoftverrendszerek is felhasználhatják, szemléltetni is fogom ennek lehetőségeit. Továbbá a kereskedelmi rendszer az új API segítségével nagy előnyre tesz szert az ERP-k piacán, mivel még napjainkban is alig-alig találkozni jó megoldásokkal. 3

4 A téma megnevezése: Tartalmi összefoglaló A megadott feladat megfogalmazása: A cél, egy meglévő és működő, Microsoft.NET alapú webes kereskedelmi rendszer kibővítése web-szolgáltatásokkal, és ezen keresztül a RESTful szolgáltatások előállítási lehetőségeinek bemutatása Microsoft WCF-ben. A megoldási mód: A RESTful architektúra stílus útmutatóját követve történik a tervezés, a kivitelezés pedig Microsoft WCF-ben, C# nyelven. A kibővítendő kereskedelmi rendszer komponensei lettek újrahasznosítva. A tesztelés, beüzemelés és optimalizálás szintén Microsoft eszközökkel zajlott. Alkalmazott eszközök, módszerek: A fejlesztés Microsoft.NET 4-ben, C# nyelven zajlott WCF WebHttp szolgáltatásokkal. A fő fejlesztőeszköz a Visual Studio 2010 (Ultimate) volt, továbbá a tesztelés is a Visual Studio Web Performance Test megoldásaival valósult meg. A dolgozatban bemutatásra került a kibővített alaprendszer érintett szegmense is. A RESTfult architektúra stílus erőforrásorientált tervezési útmutatója lett alkalmazva. A módszerek és minták javarésze elismert szakírók által alátámasztottak, továbbá az egyedi ötletek részletesen be lettek mutatva. Elért eredmények: A kívánt RESTful szolgáltatás elkészült, dokumentálva lett, átesett egy automatizált tesztelésen, telepítve és teljesítmény tesztek útján optimalizálva lett. Az elkészült terméket a dolgozat születése közben már felhasználta egy másik web-es szoftver. A kialakítás és a kommunikáció röviden be lett mutatva. Kulcsszavak: REST és RESTful szolgáltatások, Microsoft WCF WebHttp szerveroldali megoldások, Data Contract sorosítás, API kulcsos hitelesítés, gyorsítótárazás, komponens-orientált programozás, Visual Studio Web Performance Test, IIS 7.5, ASP.NET 4, SQL Server

5 Tartalomjegyzék 1. BEVEZETÉS A REST VILÁG A SOAP A REST A RESTFUL-SÁG REST A GYAKORLATBAN Az erőforrások meghatározása Az URI-k megtervezése Az egységes interfész implementálása A reprezentáció megtervezése Kapcsolatok kialakítása TERVEZÉSI MINTÁK, SPECIÁLIS MEGOLDÁSOK Tervezési minták erőforrásokhoz A WCF RESTFUL PROGRAMOZÁSI MODELLJE WCF A SZERVEROLDALON A WEBHTTP SZOLGÁLTATÁSOK A WCF WebHttp szolgáltatások adottságai fejlesztői szempontból A DATA CONTRACT SOROSÍTÁS Deklaratív programozás Öröklés és interfészek implementációi Hivatkozások és körkörös hivatkozások Verzió tolerancia Null és üres értékek Gyűjtemények Néhány sajátosság AZ ALAPRENDSZER ISMERTETÉSE AZ ÉRINTETT SZERELVÉNYEK ISMERTETÉSE A RENDSZER NÉHÁNY FONTOS TULAJDONSÁGA Interfészek és implementációik Komponens alapú biztonság A lokalizáció Példányosítás, mentés, törlés és listázás KIVITELEZÉS A REST WCF PROJEKT LÉTREHOZÁSA AZ ERŐFORRÁSOK MEGHATÁROZÁSA Az érintett témakörök Kompozitok A közös interfész AZ URI-K MEGTERVEZÉSE Az URI template-ek megtervezése Az URI template-ek implementálása AZ EGYSÉGES HTTP INTERFÉSZ IMPLEMENTÁLÁSA A REPREZENTÁCIÓ MEGTERVEZÉSE A Data Contract dekoráció és részleges objektumok A kívánt reprezentáció megadása Nagyobb gyűjtemény jellegű erőforrások lapozhatósága ÖSSZEKAPCSOLHATÓSÁG A Link-ek inicializálása Link relációk HITELESÍTÉS Az API kulcsos hitelesítés implementálása ÁLLAPOTKÓDOK

6 Globális hibakezelés A 201 státusz kód DOKUMENTÁCIÓ Help Link-ek az erőforrásokban TESZTELÉS Egységtesztek Teszteredmények Egy kis technológiai affér TELEPÍTÉS ÉS OPTIMALIZÁLÁS IGÉNY A SZOLGÁLTATÁSA Kialakítás és kommunikáció GYORSÍTÓTÁRAZÁS A átmenetileg tárolható erőforrások meghatározása A cache-elés beállítása A hitelesítés Terhelésteszt ÖSSZEFOGLALÁS I. SZ. MELLÉKLET IRODALOMJEGYZÉK NYILATKOZAT... HIBA! A KÖNYVJELZŐ NEM LÉTEZIK. 6

7 1. Bevezetés Diplomamunkámmal célom, hogy egy meglévő és működő, Microsoft.NET alapú webes kereskedelmi rendszert kibővítsek web-szolgáltatásokkal, és ezen keresztül bemutassam a RESTful szolgáltatások előállításának módjait Microsoft WCF-ben. Az elkészült termékkel könnyedén össze lehet kötni az alaprendszert más rendszerekkel, áthidalva a platformok közötti differenciákat és a kényes biztonsági kérdéseket. A diplomamunka első fejezeteiben bemutatom a REST alapvető koncepcióját és az ilyen architektúrájú szolgáltatások előállításának elméleti és gyakorlati módját. Majd ismertetem a WCF érintett szegmensét, csakis a kiszolgálóoldalra koncentrálva. Bemutatom a szóban forgó kereskedelmi rendszer érintett részegységeit, továbbá azt is, hogy milyen apróbb módosításokat kellett alkalmaznom azokon a szolgáltatás kivitelezését megelőzően. Majd részletesen szemléltetem a kivitelezés minden lépését a dolgozat elméleti bevezetőjére építve. A dolgozat utolsó fejezetei a dokumentálást, a tesztelést, a telepítést és az optimalizálást részletezik. Nagy kihívást jelentett egy koros és nagyméretű rendszert kibővíteni modern technológiájú megoldásokkal. Számtalan zsákutcába tévedhetnek a tervezők ilyen esetben, és gyakran ekkor születnek a költséges félmegoldások. Legtöbbször ugyanis újabb eszközökkel fejlesztett, modernebb szemléletű rendszereknél kisebb kockázattal kell számolniuk a szakembereknek. Dolgozatommal igazolom, hogy régebbi.net-es rendszereket is hatékonyan fel lehet készíteni a jövő igényeire. Az elkészített web-szolgáltatásokat akár más szoftverrendszerek is felhasználhatják, szemléltetni is fogom ennek lehetőségeit. Így a kereskedelmi rendszer az új API segítségével nagy előnyre tesz szert az ERP-k piacán, mivel még napjainkban is alig-alig találkozni jó megoldásokkal. 7

8 2. A REST világ A REST (Representational State Transfer) rendkívül széles körben alkalmazott megoldás. A Google, a Microsoft Azure, az Amazon, a Facebook, a Twitter, a Flicker, a Digg rendszerek rendre rendelkeznek REST API-val. De technológiákat is említhetünk, amelyek használják, vagy épp speciális implementációjuk a REST szolgáltatásoknak: ilyen az RSS, az Atom. Nem is meglepő, hogy a Microsoft vezető technológiái is támogatják a REST szolgáltatásokat; a WCF, a korábbi ADO.NET Services és a Silverlight. A fejezet célja, hogy bemutassam a REST-et és segítsem a ráhangolódást az erőforrás orientál gondolkodásra, a ROA-ra (Resource-Oriented Architecture) [1]. A továbbiakban néhány elemi tény fog felmerülni, amivel már szinte minden ember megismerkedett, aki valaha is használta a webet. A web legfontosabb tulajdonságai, ami miatt olyan gyorsan elterjedt, a következők: Címezhető erőforrások (URI-kkel) Standard erőforrás formátumok Egységes felület (uniform interface) az erőforrások használatához Állapotnélküliség az ügyfél és a kiszolgáló interakciója között Hiperhivatkozások (összekapcsolás), melyek segítségével navigálhatunk az erőforrások között Ezek a tulajdonságok teszik oly naggyá a webet. Mégis amikor web-szolgáltatásokról beszélünk, a legtöbb szakembernek a SOAP-alapú szolgáltatások jutnak eszükbe, holott a SOAP egyáltalán nem a webre született A SOAP A SOAP-ot tipikusan a távoli eljáráshívásra használják. Azt írja le és valósítja meg, hogy két végpont miként kommunikálhat. Továbbá úgy tervezték, hogy protokoll-független legyen. Ezért bátran kijelenthetjük, hogy nem feltételül a web az a csatorna, amin a SOAP érvényesülhet, mivel elméletileg nem csak a weben működhetne. Emiatt nem használja ki a web legfontosabb tulajdonságait. Például a SOAP szolgáltatások nem az URI-kre összpontosítanak, inkább a műveleteket helyezik előtérbe. Legtöbbször egyetlen URI-hez lesznek felsorakoztatva az elvégezhető műveletek. Így az 8

9 erőforrások összekapcsolása, mint a web talán legfontosabb tulajdonsága, háttérbe szorul, mivel SOAP szolgáltatásokat kevésbé érdemes hivatkozásokkal összekötni. Szintén érdekes dolog, hogy minden alkalommal, amikor egy SOAP szolgáltatást tervezünk, egy új interfészt készítünk, és ennek az interfésznek a későbbi módosítása könnyen befolyásolhatja a szolgáltatást felhasználó rendszerek működését. Illetve nem szabad megfeledkeznünk arról sem, hogy a SOAP szolgáltatások tipikusan a HTTP POST műveletét alkalmazzák, melynek hatása sehol nincs definiálva legalábbis a HTTP-ben nincs, azaz nem egyértelmű az eredményük. Továbbá a SOAP szolgáltatások nem jól gyorsítótárazhatók, mert legtöbbször nem támogatják a GET műveleteket [2] A REST A REST egy architektúrális stílus, egy tervezési szempont web-szolgáltatások 1 készítéséhez, ami 100%-ban a HTTP-re épült. Azaz annak minden tulajdonságát kihasználja, továbbá útmutatót nyújt a REST alapú szolgáltatások előállításához is. A SOAP nem architektúra stílus, semmilyen megszorítást vagy útbaigazítást nem ad, hogy egy szolgáltatás hogyan nézzen ki. Ellenben a REST szolgáltatások a REST előírásait követik. Míg a SOAP szolgáltatások inkább a műveletekre koncentrálnak, a REST szolgáltatások inkább az erőforrásokat veszik alapul, azaz erőforrások útján kommunikálnak a felek. Minden erőforrás egy egyedi URI-vel van beazonosítva. A felhasználó legyen az egy alkalmazás vagy egy internetes böngésző előtt ülő személy a HTTP egységes interfészét alkalmazza az URI által beazonosított erőforrás használatakor. Tehát a REST szolgáltatások inkább főnevekkel (pl.: erőforrások) foglalkoznak, míg a SOAP szolgáltatások igékkel (HTTP és SOAP műveletek) [3] A RESTful-ság Azok a web-szolgáltatások, melyek a REST architektúrális stílust követik, RESTful szolgáltatások. Leonard Richardson és Sam Ruby voltak, akik elsőnek összefoglalták a RESTful szolgáltatások lényegét. A későbbiekben rengeteg szakkönyv jelent meg a témakörben, általános témákkal és technológiákhoz specializált témákkal, mint a Java, Ruby, 1 Továbbiakban, a dolgozatomban a web-szolgáltatás alatt a REST szolgáltatásokat fogom érteni. A SOAP szolgáltatások továbbra is SOAP szolgáltatásokként fogom megnevezni. 9

10 PHP és nem utolsó sorban a.net. A dolgozatom részben ezekből táplálkozik. A RESTfulság előírásainak bemutatása könyveket emészt fel, ezért dolgozatomban csak az általam érintett megoldásokon keresztül írom le azokat. A szakirodalomban és a fejlesztők kommunikációjában gyakran találkozni azzal a kijelentéssel, hogy egy bizonyos problémára egy megoldás, nem teljesen vagy teljes egészében RESTful. A dolgozatomban is számos alkalommal teszek ilyen említést. Arra, hogy egy problémára hogyan találok RESTful megoldást, a korábbi tapasztalataim, a szakirodalom és a fejlesztői kommunikációk nyújtanak tudományos segítséget, továbbá a józan és egyszerű gondolkodás REST a gyakorlatban A REST világgal történő ismerkedéskor érdemes a weboldalakból kiindulni. Bizonyos értelemben egy weboldal is egy REST szolgáltatás. A fejezetben bemutatom, hogy a REST szolgáltatások tervezésekor mely lépéseket kell elvégezni, továbbá kifejtem az alapvető fogalmakat. Szintén kitérek a szigorúbb RESTful szolgáltatások előírásaira is Az erőforrások meghatározása Az erőforrás egy olyan valami, ami tárolható egy számítógépen és reprezentálható bitek folyamaként. Azaz lehet egy dokumentum, egy adatbázis egy rekordja vagy épp egy algoritmus eredménye. Továbbá egy erőforrás lehet egy fizikai objektum, mint egy alma, vagy épp egy absztrakt fogalom is, viszont ezen erőforrások megjelenítése kissé problémás lehet. Nagyvonalakban állíthatjuk, hogy vannak dinamikus és statikus erőforrások. Erőforrások lehetnek a következők: Cikk a Silverlight 4-ről Útvonalterv az iskola és az otthonom között Dokumentáció a Microsoft SQL Server 2008 R2-höz Szoftverfrissítés a Windows 7-hez Ismerőseim a Facebook-on A következő öt prímszám 1024 felett A 223-as rendelés tételei 10

11 REST szolgáltatások tervezésekor az első és legfontosabb lépés az erőforrások meghatározása. Tehát meg kell kérdeznünk magunktól, hogy mik azok a dolgok, amiket közzé szeretnénk tenni. Ezekre először csak összemosódott adathalmazokként tekintünk, majd később ezeket pontosítjuk és átalakítjuk erőforrásokká. [4] [5] Az URI-k megtervezése Az erőforrást az teszi erőforrássá, hogy azonosítható URI-vel. Tehát minden erőforrásnak kell lennie URI-jének, legalábbis a weben igen. Fontos, hogy az URI-k leírók legyenek, így még pontosabb lesz a kapcsolat az erőforrás és annak URI-je között. Továbbá ha az URI jól olvasható, értelmezhető akár az ember számára is, akkor könnyedén lehet vele dolgozni. Az is széppé teszi a munkát, hogy egy erőforrásnak akár több URI-je is lehet, így ha szeretnénk más és más nézőpontból is vizsgálhatjuk ugyanazon erőforrásokat. Lehetséges URI-k: (REST a wiki-n) (A 223-as rendelés) stb. Az URI-k létrehozása a következő lépés a tervezési folyamatban. Mondhatni ez a munka oroszlán része. A pontos URI design nélkülözhetetlen a tervezési folyamat további lépéseire, illetve a kész szolgáltatások felhasználhatóságára nézve. Itt nevezzük el a korábban meghatározott erőforrásokat. Fontos feltétel, hogy az URI megmagyarázza, hogy pontosan micsodán és miért fog dolgozni a kiszolgáló számítógép. Az erőforrás-uri leképezés legfontosabb szabályai: Használjunk útvonal változókat (path variable) a hierarchia leképezéséhez: /parent/child. Használjunk írásjeleket az útvonal változókban, ahol nem tudunk hierarchiát alkalmazni:/parent/child1;child2. Néhány esetben számíthat az útvonal változók sorrendje. Ekkor többféle írásjelet használunk, de tipikusan a vesszőt és pontos vesszőt. Használjunk lekérdezési változókat (query variable), mint algoritmus paraméterei, ha algoritmikus erőforrásról beszélünk: /search?q=akarmi&start=20. [6] [7] 11

12 Az egységes interfész implementálása Mint korábban említettem, egy SOAP szolgáltatás tervezésekor műveleteket hozunk létre. Valójában ekkor egy interfészt tervezünk az alkalmazásunknak. De ez az interfész nem egységes, hiszen teljesen másképp néz ki, mint egy másik cég által fejlesztett rendszer SOAP szolgáltatása. De akár ugyanezen a rendszeren belül egy másik SOAP szolgáltatás is teljesen eltérő felülettel rendelkezhet. A probléma tehát, hogy az egységesség híján állandóan új interfészek megalkotásán kell gondolkozniuk a SOAP szolgáltatás fejlesztőknek. Másfelől ha egy másik cég fejlesztője szeretné használni a szóban forgó SOAP szolgáltatást, akkor meg kell tanulnia ezt az interfészt, és gyakran azt is, hogy milyen hatásai vannak a benne tartalmazott műveleteknek. A REST-nél szerencsére másképp van. Itt a HTTP által definiált műveleteket más szóval igéket, vagy verbs-öket használjuk az URI-k által azonosított erőforrásokon. Ezek a műveletek alkotják az egységes interfészt (1. ábra) [8]. GET Visszaad egy erőforrást Garantáltan nincs mellékhatása (SAFE) Gyorsítótárazható POST Létrehoz egy új erőforrást Nem biztonságos, a művelet hatása nincs pontosan definiálva a HTTP által (RFC 2616) PUT Módosít egy létező erőforrást Ha ismert az URI, akkor erőforrás létrehozásához használjuk Akárhányszor hívjuk, mindíg ugyanaz fog történni (idempotens) DELETE Eltávolít egy erőforrást Akárhányszor hívjuk, mindíg ugyanaz fog történni (idempotens) 1. ábra Az egységes interfész legfontosabb műveletei Ha REST szolgáltatásokkal dolgozunk, akkor elegendő a fenti egységes interfészt megtanulnunk és alkalmaznunk. Web-szolgáltatás tervezéskor csak azt kell meghatároznunk, hogy egyes erőforrásokon mely műveleteket engedélyezzük, illetve web-szolgáltatások 12

13 felhasználásakor csak azt kell megvizsgálnunk, hogy mely műveletek támogatottak. Természetesen egy erőforrás létrehozásakor nem szükséges az egységes interfész minden verb-jét implementálnunk. Tehát a tervezési folyamat következő lépése az egységes interfész megvalósítása az erőforrásokon. A munkában nem korlátoz a REST, hiszen teljes mértékben a fejlesztőre van bízva, hogy milyen műveleteket engedélyez. Viszont figyelembe kell venni, hogy a webszolgáltatás a jövőben milyen környezetben fog futni, hiszen elképzelhető, hogy a webkiszolgálók, vagy védelmi vonalak úgy vannak bekonfigurálva, hogy a fenti interfészből csak pár műveletet támogassanak. Tipikusan a PUT és a DELETE áll a problémás kulcsszavak sorában. Kliensoldalon is lehetnek problémák. Korábban a böngészők sem támogatták a PUT és DELETE műveleteket, és ez a böngészőben futó kliensoldali alkalmazásoknál vethetett fel tervezési szintű kérdéseket. Például a Silverlight 2-ben még nem voltak támogatottak a szóban forgó műveletek [9]. A POST műveletet, ha lehetőség nyílik rá, a web-szolgáltatás fejlesztők elkerülik. Azok a REST stílusú web-szolgáltatások, amelyek csupán POST és GET műveleteket alkalmaznak, vagy még rosszabb esetben GET műveletek által módosítanak erőforrásokat, egyáltalán nem nevezhetők RESTful-nak. RESTful-ok azok a web-szolgáltatások, melyek az egységes interfészt tiszteletben tartva működnek A reprezentáció megtervezése A reprezentáció így definiálható; minden hasznos információ egy erőforrás állapotáról [10]. Mivel egy fizikai objektum nem adat, nem is feltételezhetjük, hogy az a weben elérhető. Viszont a meta-információik felhasználhatók az erőforrás reprezentációjaként. Kicsit pontosítva, ha egy erőforrás egy könyv, mint fizikai objektum, akkor annak reprezentációja lehet a meta-információja, például a borítójának egy fényképe, a könyv alapadatai, vagy maga a könyv digitális formában. Visszafele gondolkodva pedig, egy alkalmazásnak elküldhetünk meta-információkat is egy objektumról, amiből az alkalmazás erőforrást állít elő. Pontosan ez történik, amikor kitöltjük egy regisztrációs űrlapon a személyi adatainkat, amiből feltételezhetően egy bejegyzés születik a regisztrált ügyfeleket tartalmazó adatbázis táblában. Illetve meglévő erőforrásnak is készülhet új reprezentációja, például amikor egy fényképet küldünk el egy alkalmazásnak és az átkonvertálja, átméretezi, vízjellel látja el azt. 13

14 Az erőforrások megjelenése rendkívül változatos. Korábban a web-en média típusoknak (media types, HTTP fejlécekben Content-type) nevezték a szakemberek az erőforrások reprezentációit. Ha egy weboldalt tekintünk erőforrásnak, akkor a reprezentáció HTML vagy XHTML. Üzleti rendszerekben legtöbbször XML vagy manapság divatos JSON (JavaScript Object Notation) a használt. Továbbá a hírforrásoknál az RSS és az Atom a leggyakoribb. Természetesen egyéb erőforrások, mint például az audio-video erőforrások, képek, ikonok a saját, legtöbbször formátum-specifikus reprezentációval rendelkeznek. De a reprezentáció nem csak média típusokra terjed ki. Egy szöveges dokumentum reprezentációja lehet a nyelvi kultúra, amiben olvasható. Vagy épp egy termék ára, mely értékének szöveges formátuma illetve pénzneme is a reprezentációtól függhet. A REST lehetőséget ad arra, hogy egy erőforrásnak több reprezentációja is lehessen. Célszerű a reprezentációt az erőforrás URI-jében alkalmazni: (A 223-as rendelés XML alakban) (A 223-as rendelés JSON alakban) (A 223-as rendelés XHTML alakban) A nyelvi kultúrák esetén például: (A 101-es dokumentum magyarul) (A 101-es dokumentum angolul) A tervezési folyamat újabb és legtöbb esetben befejező lépése az erőforrásaink reprezentációinak meghatározása. Teljes mértékben szabad keze van a fejlesztőknek a formátumok kiválasztásában. Viszont egy erőforrás elérésekor a kívánt reprezentáció megadása több féle módon is történhet. A leginkább javasolt megoldás, hogy ami csak lehet, kerüljön bele az URL-be. Ellenben használhatók a HTTP kérés fejlécek is. Ez utóbbi hasznos lehet a kívánt nyelvi kultúra meghatározáskor, a böngészők az Accept-Language fejlécet használják erre. Mindkét megoldás RESTful [11]. Figyelembe kell venni, hogy a web-szolgáltatást gyakran más rendszerek fogják felhasználni. Így a megfelelő reprezentáció létkérdés. Továbbá kényes probléma, ha a reprezentáció megváltozik, miközben a szolgáltatást más rendszerek használják. Gyakorlati példa, ha egy rendelés XML reprezentációja szerkezetileg átalakul, és a kliens rendszerek erről nem értesülnek. 14

15 Kapcsolatok kialakítása A web talán legfontosabb tulajdonsága a linkelhetőség. Azaz hyperlink-ek segítségével kapcsolatok létesítése az erőforrások között. Egyik erőforrásról a másikra navigálhatunk, anélkül, hogy gondolkoznunk kellene a kívánt erőforrás URI-jén. Továbbá így lehet az állapot nélküliségnek állapotot adni. Gondolva például egy találati lista lapozhatóságára, ahol az oldalszámok hiperhivatkozások, így tudjuk, hogy hányadik oldalon vagyunk. Egy üzleti rendszerben rendkívül előnyös, ha egy XML reprezentációjú rendelési tételből le tudja tölteni a kliensalkalmazás a megrendelt terméket, esetleg a megrendelő adatait, mint erőforrásokat. Ehhez az kell, hogy a link-eknek megfelelő formában az erőforrásban kell szerepelniük. A tervezési folyamat utolsó lépése az erőforrások közötti kapcsolatok felépítése linkek segítségével. Ez nem egyszerű dolog, mivel a link-ek reprezentációfüggők. Egy JSON formátumú erőforrásban nem néz ki szépen XML formátumú erőforrásra mutató link. Vagy ha mégis megengedünk ilyet, akkor tájékoztatni kell a klienseket arról, hogy milyen reprezentációjú erőforrásra mutat egy-egy link. Továbbá a kliensalkalmazások gyakran rákeresnek az erőforrásokban a linkekre, így gondoskodni kell a link-ek egységes megjelenéséről. Vannak erőforrások, amikbe nem lehet linkeket helyezni, tipikusan ilyenek a bináris adatok. Ekkor válaszfejlécek használata javasolt. [12] 2.5. Tervezési minták, speciális megoldások Az évek során a tervezési folyamat minden lépéséhez kialakultak frappáns tervezési minták, melyeket célszerű ismernie a fejlesztőnek, ha RESTful szolgáltatásokat készít. Dolgozatomban is néhány alkalommal alkalmazok ilyen trükköket Tervezési minták erőforrásokhoz Léteznek tervezési mintákból eredő erőforrás típusok. Ilyenek például a kompozit (composites) erőforrások, melyek több erőforrás együttesét jelentik. Legyen egy weblap a 15

16 kompozit erőforrás, ahol legtöbbször több kisebb erőforrás szerepel egy helyen. Mint amikor egy ügyfél adatlapján meg tudjuk tekinteni annak kapcsolattartóit, korábbi megrendeléseit. Ezzel a megoldással gyorsíthatjuk az adatátvitelt, hiszen nem kell minden szükséges erőforrást egyenként lekérdeznünk [13]. A vezérlő erőforrások (controller resources) hosszabb, összetettebb szerveroldali műveletekhez használjuk, melyek legtöbbször több erőforrást is manipulálnak. Ilyen megoldást használnak, amikor egy telefonban lévő partnerlistát szinkronizálnak a szerveren lévő partnerekkel. Nem kell le- majd feltöltögetni a szerveren lévő partnereket, továbbá szükségtelen üzleti logikát tervezni a szinkronizáláshoz a kliensen. Egyszerűen feltöltjük a telefonban lévő partnerlistát a szerverre, mint controller erőforrás és a szerver elvégzi a dolgát. Ezzel nagyobb teljesítményre teszünk szert, kevésbé terheljük a hálózatot, nem kell szinkronizáló üzleti logikát létrehozniuk a kliensek fejlesztőinek és talán eredményt is kapunk a szinkronizálás hatásairól [14]. A tranzakciók is támogatottak a HTTP-n. Például, amikor egy banki tranzakcióról van szó, ahol az egyik számláról kell egy másikra utalni. A tranzakciót kezelhetjük erőforrásként, mint banki átutalás tranzakció, létrehozhatjuk (POST, PUT), vagy akár törölhetjük (DELETE). Egy hosszabb lefolyású tranzakciót, mint egy helyfoglalást a repülőn szintén így kezelhetünk [15]. 16

17 3. A WCF RESTful programozási modellje A WCF kliensoldalon és szerveroldalon is segíti a fejlesztők munkáját, szolgáltatások egyszerű létrehozásában és azok vagy épp más rendszerek szolgáltatásainak felhasználásában is. A SOAP szolgáltatások mellett a REST szolgáltatások létrehozását is bőkezűen támogatja. A fejezetben a WCF web programozási modellre koncentrálok, melyet legtöbbször WebHttp-nek, WebHttp Services-nek neveznek. Továbbá csak a szerveroldali viselkedést mutatom be WCF a szerveroldalon A WCF feladata szerveroldalon, hogy lefülelje a hálózaton át érkező üzeneteket és azokat feldolgozva továbbítsa a szolgáltatás kódjához, a fejlesztő implementációjához. Illetve üzenetet küldjön ki a hálózatra. Üzenet Hálózat Diszpécser 2. ábra A WCF szerveroldali csatorna verme Amikor megnyílik egy WCF szerveroldali végpont, a WCF csatornafigyelő (channel listener) segítségével létrehoz egy hálózat figyelőt, un. átviteli csatornát. A csatornafigyelő valójában egy gyár objektum, ami azért felelős, hogy előállítsa a szerveroldali figyelő infrastruktúrát. 17

18 Az üzenetértelmező a hálózati üzenetet átalakítja a WCF számára értelmezhető üzenetté. Ez az üzenet System.ServiceModel.Channels.Message típusú, melyből komplex.net objektumokat is vissza lehet állítani. A protokoll csatornák opcionálisak a modellben. Ezek segítségével lehet bizonyos stílusú architektúrákat implementálni. Fontosak lehetnek továbbá a nagy biztonságú és nagy megbízhatóságú szolgáltatások készítésekor. A diszpécser a beérkező üzenetek számára megfelelő metódusokat hívja meg. Ezek a metódusok már a fejlesztők kódját tartalmazzák. Először megvizsgálja, hogy melyik metódus a megfelelő, majd az üzenetet visszaállítja a kívánt.net típussá, és meghívja a metódust a szolgáltatást. Ezek együttesen alkotják a csatorna vermet, mely létrehozásához a WCF kötéseket (bindings) használ. A kötések konfiguráció beállítások, melyek konfigurációs file-ban vagy a memóriában, objektumként is elhelyezkedhetnek. Leggyakrabban a konfigurációs file-ban tartjuk nyílván ezeket, de.net 4 óta már erre sincs szükség, deklaratív programozásra is van lehetőség. Természetesen manuális kódolással is elő lehet állítani a csatorna vermet, a fenti komponensekkel. Két generációval ezelőtt a WCF 3.0-ban csak erre volt lehetőség [16] A WebHttp szolgáltatások A System.ServiceModel.Web.dll szerelvény a 3.5-ös.NET óta segíti a fejlesztőket. Ez tartalmazza a WebHttp, és így a REST szolgáltatások létrehozásához szükséges komponenseket. A System.ServiceModel és a System.ServiceModel.Web névterek a lényegesek. Néhány fontosabb komponens: WebHttpBinding ez a kötés a HTTP(S) átviteli csatornát és az üzenet értelmezőt (TextMessageEncoder) állítja be. WebHttpBehavior ez állítja be a WCF diszpécser rétegét, hogy a REST kéréseket a megfelelő szolgáltatás CLR metódusához irányítsa routing. Továbbá ez konfigurálja be a sorosító/visszaállító réteget. WebOperationContext ennek a környezeti komponensnek a WebOperationContext típusú, osztályszintű Current nevű tulajdonságával lehet elérni a kérelmek és válaszok minden részletét. Ez rendkívül fontos objektum, például ha HTTP kérésekből szeretnénk adatokat kinyerni, mint a HTTP fejlécek. 18

Flash és PHP kommunikáció. Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft

Flash és PHP kommunikáció. Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft Flash és PHP kommunikáció Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft A lehetőségek FlashVars External Interface Loadvars XML SOAP Socket AMF AMFphp PHPObject Flash Vars Flash verziótól függetlenül

Részletesebben

QBE Édes Otthon lakásbiztosítás tarifáló webservice. Fejlesztői dokumentáció 1.0.2

QBE Édes Otthon lakásbiztosítás tarifáló webservice. Fejlesztői dokumentáció 1.0.2 QBE Édes Otthon lakásbiztosítás tarifáló webservice Fejlesztői dokumentáció 1.0.2 Az ebben a dokumentumban található információ a FoxArt Kft. tulajdona, és bizalmas anyagként került átadásra. Az anyag

Részletesebben

1. fejezet Bevezetés a web programozásába (Balássy György munkája)... 11 Az internet működése... 11

1. fejezet Bevezetés a web programozásába (Balássy György munkája)... 11 Az internet működése... 11 Tartalomjegyzék 1. fejezet Bevezetés a web programozásába (Balássy György munkája)... 11 Az internet működése... 11 Géptől gépig... 11 Számok a gépeknek... 13 Nevek az embereknek... 14 Programok egymás

Részletesebben

Bevezetés Működési elv AJAX keretrendszerek AJAX

Bevezetés Működési elv AJAX keretrendszerek AJAX AJAX Áttekintés Bevezetés Működési elv AJAX-ot támogató keretrendszerek Áttekintés Bevezetés Működési elv AJAX-ot támogató keretrendszerek Áttekintés Bevezetés Működési elv AJAX-ot támogató keretrendszerek

Részletesebben

NETinv. Új generációs informatikai és kommunikációs megoldások

NETinv. Új generációs informatikai és kommunikációs megoldások Új generációs informatikai és kommunikációs megoldások NETinv távközlési hálózatok informatikai hálózatok kutatás és fejlesztés gazdaságos üzemeltetés NETinv 1.4.2 Távközlési szolgáltatók és nagyvállatok

Részletesebben

Tartalomjegyzék. Bevezetés. 1. A.NET 3.5-keretrendszer 1. A korszerű alkalmazások felépítésének kihívásai... 2

Tartalomjegyzék. Bevezetés. 1. A.NET 3.5-keretrendszer 1. A korszerű alkalmazások felépítésének kihívásai... 2 Bevezetés xv Mitől tartozik egy platform a következő generációhoz?... xvi Mennyire jelentős az egyre újabb.net-változatok közötti különbség?... xviii Mit jelentett a Windows Vista megjelenése a Microsoft.NET

Részletesebben

RBLDNS DNS-based blocklists management felhasználói kézikönyv

RBLDNS DNS-based blocklists management felhasználói kézikönyv RBLDNS DNS-based blocklists management felhasználói kézikönyv (INTEGRITY Kft. 2013. 06. 27.) RBLDNS Webes kezelőfelülete Az INTEGRITY által működtetett RBLDNS rendszer webes felületét a spamdns.eu/rbl/

Részletesebben

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja 1 / 15 Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja Vajna Miklós 2012. január 24. Tartalomjegyzék 2 / 15 1 Bevezető 2 Motiváció 3

Részletesebben

RBLDNS DNS-based blocklists management felhasználói kézikönyv

RBLDNS DNS-based blocklists management felhasználói kézikönyv RBLDNS DNS-based blocklists management felhasználói kézikönyv (INTEGRITY Kft. 2013. 12. 9.) Bevezető ismertetés Az RBLDNS rendszer a hagyományos DNS protokollra épülő rendszer, melyet elsősorban black

Részletesebben

Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.

Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal. Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.hu. 1 Tartalom 1. BEVEZETŐ... 3 1.1 Architektúra (terv) felülvizsgálat...

Részletesebben

Gyakorlati vizsgatevékenység A

Gyakorlati vizsgatevékenység A Gyakorlati vizsgatevékenység A Szakképesítés azonosító száma, megnevezése: 481 04 0000 00 00 Web-programozó Vizsgarészhez rendelt követelménymodul azonosítója, megnevezése: 1189-06 Web-alkalmazás fejlesztés

Részletesebben

Web programoz as 2009 2010

Web programoz as 2009 2010 Web programozás 2009 2010 Áttekintés A web rövid története Kliens szerver architektúra Néhány alapfogalom Kliens- illetve szerver oldali technológiák áttekintése Áttekintés: miről lesz szó (kurzus/labor/vizsga)

Részletesebben

Példa webáruház kialakítás rendszerdokumentáció

Példa webáruház kialakítás rendszerdokumentáció Példa webáruház kialakítás rendszerdokumentáció DWAM Webáruház integrációja meglévő belső ERP rendszerhez. A webáruház valamennyi termékkel és megrendeléssel összefüggő adatát a belső rendszer (..) tárolja,

Részletesebben

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese

Részletesebben

Szegedi Tudományegyetem Informatikai Tanszékcsoport SZAKDOLGOZAT. Fertői Ferenc

Szegedi Tudományegyetem Informatikai Tanszékcsoport SZAKDOLGOZAT. Fertői Ferenc Szegedi Tudományegyetem Informatikai Tanszékcsoport SZAKDOLGOZAT Fertői Ferenc 2010 Szegedi Tudományegyetem Informatikai Tanszékcsoport 3-dimenziós táj generálása útvonalgráf alapján Szakdolgozat Készítette:

Részletesebben

SOAP komponensek Delphiben

SOAP komponensek Delphiben SOAP komponensek Delphiben (Simple Object Access Protocol) Bevezetés -Azegyszerűen programozható webhozzáférés azt jelenti, hogy a fejlesztők saját programjukat a weben elérhető szolgáltatásokból építik

Részletesebben

Gyakorlati vizsgatevékenység B

Gyakorlati vizsgatevékenység B Gyakorlati vizsgatevékenység Szakképesítés azonosító száma, megnevezése: 481 04 0000 00 00 Web-programozó Vizsgarészhez rendelt követelménymodul azonosítója, megnevezése: 1189-06 Web-alkalmazás fejlesztés

Részletesebben

PRECÍZ Információs füzetek

PRECÍZ Információs füzetek PRECÍZ Információs füzetek Információk, Módszerek, Ötletek és Megoldások a Precíz Integrált Ügyviteli Információs rendszerhez 3. EXCEL adatkapcsolat (mod. 2009.07.) Ügyviteli nyilvántartások és EXCEL formátumú

Részletesebben

Elektronikus levelek. Az informatikai biztonság alapjai II.

Elektronikus levelek. Az informatikai biztonság alapjai II. Elektronikus levelek Az informatikai biztonság alapjai II. Készítette: Póserné Oláh Valéria poserne.valeria@nik.bmf.hu Miről lesz szó? Elektronikus levelek felépítése egyszerű szövegű levél felépítése

Részletesebben

XML Webszolgáltatás alapú osztott alkalmazás fejlesztése Johanyák Zsolt Csaba 1

XML Webszolgáltatás alapú osztott alkalmazás fejlesztése Johanyák Zsolt Csaba 1 XML Webszolgáltatás alapú osztott alkalmazás fejlesztése Johanyák Zsolt Csaba 1 A gyakorlat célja a webszolgáltatások létrehozásának és igénybe vételének elsajátítása egyszerű példákon keresztül. 1. Két

Részletesebben

Csináljunk az adatból információt! A Lone-Soft listázó keretrendszerrel

Csináljunk az adatból információt! A Lone-Soft listázó keretrendszerrel Csináljunk az adatból információt! A Lone-Soft listázó keretrendszerrel A piacon lévő ügyviteli szoftverek jó részének legnagyobb hibája, hogy a letárolt adatokat nem képesek a felhasználó által hasznosítható

Részletesebben

Flex: csak rugalmasan!

Flex: csak rugalmasan! Flex: csak rugalmasan! Kiss-Tóth Marcell http://kiss-toth.hu marcell@kiss-toth.hu Magyarországi Web Konferencia 2006 2006. március 18. tartalom bevezető Adobe Flex alternatív technológiák bevezető az Internetnek

Részletesebben

Felhasználói dokumentáció. a TávTagTár programhoz. Készítette: Nyíri Gábor, hdd@nc-studio.com GDF Abakusz regisztrációs kód: GDFAba43

Felhasználói dokumentáció. a TávTagTár programhoz. Készítette: Nyíri Gábor, hdd@nc-studio.com GDF Abakusz regisztrációs kód: GDFAba43 a TávTagTár programhoz Készítette: Nyíri Gábor, hdd@nc-studio.com GDF Abakusz regisztrációs kód: GDFAba43 Tartalomjegyzék Futási feltételek... 3 Telepítés... 3 Indítás... 3 Főablak... 4 Új személy felvétele...

Részletesebben

Tanúsítványkérelem készítése, tanúsítvány telepítése Microsoft Internet Information szerveren

Tanúsítványkérelem készítése, tanúsítvány telepítése Microsoft Internet Information szerveren Tanúsítványkérelem készítése, tanúsítvány telepítése Microsoft Internet Information szerveren Tartalomjegyzék 1. BEVEZETÉS...3 2. A MICROSOFT IIS INDÍTÁSA...3 3. TITKOS KULCS GENERÁLÁSA...3 4. TANÚSÍTVÁNYKÉRELEM

Részletesebben

Szövegbányászati rendszer fejlesztése a Magyar Elektronikus Könyvtár számára

Szövegbányászati rendszer fejlesztése a Magyar Elektronikus Könyvtár számára Szövegbányászati rendszer fejlesztése a Magyar Elektronikus Könyvtár számára Vázsonyi Miklós VÁZSONYI Informatikai és Tanácsadó Kft. BME Információ- és Tudásmenedzsment Tanszék 1/23 Tartalom A MEK jelenlegi

Részletesebben

Telepítési Kézikönyv

Telepítési Kézikönyv Intelligens Dokumentum Kezelő Rendszer Telepítési Kézikönyv 1/15. oldal Dokumentum áttekintés Dokumentum címe: doknet telepítési kézikönyv Dokumentum besorolása: szoftver telepítési leírás Projektszám:

Részletesebben

Inczédy György Középiskola, Szakiskola és Kollégium Nyíregyháza, Árok u. 53. TANMENET. Informatika szakmacsoport

Inczédy György Középiskola, Szakiskola és Kollégium Nyíregyháza, Árok u. 53. TANMENET. Informatika szakmacsoport TANMENET Informatika szakmacsoport Programozási gyakorlatok III. tantárgy 12. évfolyam A osztály 2013/2014 tanév Heti óraszám: Éves óraszám: 3 óra 96 óra Készítette: Szikszai Gusztáv tanár Ellenőrizte:.

Részletesebben

Atlon XML interface fejlesztői dokumentáció. Dokumentum verzió: 3.0

Atlon XML interface fejlesztői dokumentáció. Dokumentum verzió: 3.0 Atlon XML interface fejlesztői dokumentáció Dokumentum verzió: 3.0 Az ebben a dokumentumban található információ a FoxArt Kft. tulajdona, és bizalmas anyagként került átadásra. Az anyag részben, vagy egészben

Részletesebben

Microsoft SQL Server telepítése

Microsoft SQL Server telepítése Microsoft SQL Server telepítése Az SQL Server a Microsoft adatbázis kiszolgáló megoldása Windows operációs rendszerekre. Az SQL Server 1.0 verziója 1989-ben jelent meg, amelyet tizenegy további verzió

Részletesebben

Alkalmazás technológiai frissítés migrációs és üzemeltetési tapasztalatok

Alkalmazás technológiai frissítés migrációs és üzemeltetési tapasztalatok Alkalmazás technológiai frissítés migrációs és üzemeltetési tapasztalatok Informix 11.50 upgrade esettanulmány 2011. január. 31. Átalakítandó architektúra (2009) Alapvetően az üzleti logikát tárolt eljárásokkal

Részletesebben

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-folyamat Szoftver

Részletesebben

Oralce kliens installálása Windows Server 2003-ra

Oralce kliens installálása Windows Server 2003-ra Oralce kliens installálása Windows Server 2003-ra Szükséges elofeltétel Szükséges operációs rendszer: Windows 2003 SP1 Oracle kliens verzió: 9.2.0.1.0 (9R2) Valid SQLNet.ORA fájl, amely tartalmazza a céges

Részletesebben

NEPTUN ID BMENET ID. Címtár BME VPN. vcenter VPN SVN. Trac Wiki. Wifi

NEPTUN ID BMENET ID. Címtár BME VPN. vcenter VPN SVN. Trac Wiki. Wifi Tanszék N NEPTUN ID Címtár vcenter Trac Wiki SVN Wifi VPN BMENET ID BME VPN BME címtár elérés Drupal alól Ujhelyi Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek

Részletesebben

PortaWin (PW2) Jármű mérlegelő program Mérlegelés több cég számára

PortaWin (PW2) Jármű mérlegelő program Mérlegelés több cég számára METRISoft Mérleggyártó KFT PortaWin (PW2) Jármű mérlegelő program 6800 Hódmezővásárhely Jókai u. 30 Telefon: (62) 246-657, Fax: (62) 249-765 e-mail: merleg@metrisoft.hu Web: http://www.metrisoft.hu Módosítva:

Részletesebben

Zimbra levelező rendszer

Zimbra levelező rendszer Zimbra levelező rendszer Budapest, 2011. január 11. Tartalomjegyzék Tartalomjegyzék... 2 Dokumentum információ... 3 Változások... 3 Bevezetés... 4 Funkciók... 5 Email... 5 Társalgás, nézetek, és keresés...

Részletesebben

Szolgáltatás Orientált Architektúra és több felhasználós adatbázis használata OKF keretein belül. Beke Dániel

Szolgáltatás Orientált Architektúra és több felhasználós adatbázis használata OKF keretein belül. Beke Dániel Szolgáltatás Orientált Architektúra és több felhasználós adatbázis használata OKF keretein belül Beke Dániel Alap Architektúrák ESRI építőelemek Gazdag (vastag) Kliens Alkalmazások Web Alkalmazások Szolgáltatások

Részletesebben

Web-fejlesztés NGM_IN002_1

Web-fejlesztés NGM_IN002_1 Web-fejlesztés NGM_IN002_1 Rich Internet Applications RIA Vékony-kliens generált (statikus) HTML megjelenítése szerver oldali feldolgozással szinkron oldal megjelenítéssel RIA desktop alkalmazások funkcionalitása

Részletesebben

minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01.

minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01. minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01. Weboldal 1. Előkészítés 1.1. Anyaggyűjtés 1.2. Kutatás 2. Tervezés 3. Kivitelezés 3.1. Drótváz 3.2. Grafikus tervezés 3.3. Programozás

Részletesebben

Objektumorientált programozás C# nyelven

Objektumorientált programozás C# nyelven Objektumorientált programozás C# nyelven 2. rész Öröklés és többalakúság Nemvirtuális metódusok, elrejtés Virtuális metódusok, elrejtés Típuskényszerítés, az is és as operátorok Absztrakt osztályok, absztrakt

Részletesebben

MŰSZAKI DOKUMENTÁCIÓ. Aleph WebOPAC elérhetővé tétele okostelefonon. Eötvös József Főiskola 6500 Baja, Szegedi út 2.

MŰSZAKI DOKUMENTÁCIÓ. Aleph WebOPAC elérhetővé tétele okostelefonon. Eötvös József Főiskola 6500 Baja, Szegedi út 2. Telefon: Fax: E-mail: (+36-1) 269-1642 (+36-1) 331 8479 info@ex-lh.hu www.ex-lh.hu Eötvös József Főiskola 6500 Baja, Szegedi út 2. MŰSZAKI DOKUMENTÁCIÓ Aleph WebOPAC elérhetővé tétele okostelefonon Pályázati

Részletesebben

Kiskunmajsa és környéke turisztikai térinformatikai alkalmazás

Kiskunmajsa és környéke turisztikai térinformatikai alkalmazás Kiskunmajsa és környéke turisztikai térinformatikai alkalmazás Tartalomjegyzék 1. A RENDSZER RÖVID LEÍRÁSA...3 1.1. Elvárt funkciók:...3 1.2. Specifikáció...3 1.3. Funkciók ismertetése...3 2. RÉSZLETES

Részletesebben

Szakdolgozati, TDK témajavaslatok

Szakdolgozati, TDK témajavaslatok Kiadta: IB Controll Kft. Összeállította: Nagy Imre Dokumentum verzió: v1.0 Utolsó frissítés dátuma: 2015. 03. 30. Tartalomjegyzék 1. Bevezetés...3 2. Témajavaslatok...4 2.1.1. OpenWrt / Linux szerver admin

Részletesebben

DIGITÁLIS TANÚSÍTVÁNY HASZNÁLATA AZ INFORMATIKAI PLATFORMON

DIGITÁLIS TANÚSÍTVÁNY HASZNÁLATA AZ INFORMATIKAI PLATFORMON DIGITÁLIS TANÚSÍTVÁNY HASZNÁLATA AZ INFORMATIKAI PLATFORMON 2013. 08. 12 Készítette: FGSZ Zrt. Informatika és Hírközlés Informatikai Szolgáltatások Folyamatirányítás Az FGSZ Zrt. elkötelezett az informatikai

Részletesebben

Leolvasói rendszer kialakításának koncepciója ipari mobil eszközökkel (ipari PDA-val)

Leolvasói rendszer kialakításának koncepciója ipari mobil eszközökkel (ipari PDA-val) Leolvasói rendszer kialakításának koncepciója ipari mobil eszközökkel (ipari PDA-val) A leolvasási feladat AS Szerver DB Számlázási, ügyfélszolgálati adatbázis Adatgyűjtő szerver Mobil adatgyűjtő AS szerver

Részletesebben

SABLONOZÓ KERETRENDSZER

SABLONOZÓ KERETRENDSZER SABRE SABLONOZÓ KERETRENDSZER 2014 1 FELHASZNÁLÓK Számtalan olyan vállalat és állami szervezet létezik, akik ügyfeleikkel sablonlevelek segítségével kommunikálnak, vagy sablonlevelekben értesítik partnereiket

Részletesebben

Kezdő lépések Microsoft Outlook

Kezdő lépések Microsoft Outlook Kezdő lépések Microsoft Outlook A Central Europe On-Demand Zrt. által, a Telenor Magyarország Zrt. részére nyújtott szolgáltatások rövid kezelési útmutatója 1 Tartalom Áttekintés... 3 MAPI mailbox konfiguráció

Részletesebben

WEBFEJLESZTÉS 2. ADATBÁZIS-KEZELÉS, OSZTÁLYOK

WEBFEJLESZTÉS 2. ADATBÁZIS-KEZELÉS, OSZTÁLYOK WEBFEJLESZTÉS 2. ADATBÁZIS-KEZELÉS, OSZTÁLYOK Horváth Győző Egyetemi adjunktus 1117 Budapest, Pázmány Péter sétány 1/C, 2.420 Tel: (1) 372-2500/1816 2 Ismétlés Ismétlés 3 Fájl/Adatbázis 3 4 Szerver 2 CGI

Részletesebben

Telenor Magyarország MS Office 365 telepítési útmutató

Telenor Magyarország MS Office 365 telepítési útmutató Telenor Magyarország MS Office 365 telepítési útmutató Tartalomjegyzék 1 MEGJEGYZÉS a.hu domainnel regisztrált ÜGYFELEK számára... 2 2 Bejelentkezés az O365 fiókba... 3 2.1 Az adminisztrátor felhasználói

Részletesebben

A dokumentáció felépítése

A dokumentáció felépítése A dokumentáció felépítése Készítette: Keszthelyi Zsolt, 2010. szeptember A szoftver dokumentációját az itt megadott szakaszok szerint kell elkészíteni. A szoftvert az Egységesített Eljárás (Unified Process)

Részletesebben

ALKALMAZÁS KERETRENDSZER

ALKALMAZÁS KERETRENDSZER JUDO ALKALMAZÁS KERETRENDSZER 2014 1 FELHASZNÁLÓK A cégvezetők többsége a dobozos termékek bevezetésével összehasonlítva az egyedi informatikai alkalmazások kialakítását költséges és időigényes beruházásnak

Részletesebben

Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18.

Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18. Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18. Két projekt Mindkettőben folyamatirányítás Eltérő követelmények Eltérő megoldások Dokumentum gyártási folyamat Üzemeltetés

Részletesebben

Webapp (in)security. Gyakori hibákról és azok kivédéséről fejlesztőknek és üzemeltetőknek egyaránt. Veres-Szentkirályi András

Webapp (in)security. Gyakori hibákról és azok kivédéséről fejlesztőknek és üzemeltetőknek egyaránt. Veres-Szentkirályi András Webapp (in)security Gyakori hibákról és azok kivédéséről fejlesztőknek és üzemeltetőknek egyaránt Veres-Szentkirályi András Rövid áttekintés Webalkalmazások fejlesztése során elkövetett leggyakoribb hibák

Részletesebben

NetPay technikai áttekintés partnereink számára

NetPay technikai áttekintés partnereink számára NetPay technikai áttekintés partnereink számára Üdvözöljük NetPay partnereink között. Ebben a dokumentumban megtalálja azon alapinformációkat, amelyek segítenek az on-line fizettetés megvalósításában.

Részletesebben

DAT adatcserefájl AutoCAD MAP DWG mapobject konvertáló program dokumentáció

DAT adatcserefájl AutoCAD MAP DWG mapobject konvertáló program dokumentáció H - 1161 Budapest Rákóczi út 76. Tel./Fax.: +36-1-4010159 http://www.pageos.hu toni@pageos.hu DAT adatcserefájl AutoCAD MAP DWG mapobject konvertáló program dokumentáció A program használható a TOPOBASE

Részletesebben

Osztott rendszerek. Krizsán Zoltán 1 Ficsór Lajos 1. Webalkalmazások fejlesztése tananyag. Miskolci Egyetem. Bevezetés A múlt - történelem A jelen

Osztott rendszerek. Krizsán Zoltán 1 Ficsór Lajos 1. Webalkalmazások fejlesztése tananyag. Miskolci Egyetem. Bevezetés A múlt - történelem A jelen Osztott rendszerek Krizsán Zoltán 1 Ficsór Lajos 1 1 Általános Informatikai Tanszék Miskolci Egyetem Webalkalmazások fejlesztése tananyag Tartalom Bevezetés A múlt - történelem A jelen Denition Distributed

Részletesebben

FIR WEBMODUL ALKALMAZÁS DIÁKIGAZOLVÁNY IGÉNYLÉS

FIR WEBMODUL ALKALMAZÁS DIÁKIGAZOLVÁNY IGÉNYLÉS Educatio Társadalmi Szolgáltató Nonprofit kft. FIR WEBMODUL ALKALMAZÁS DIÁKIGAZOLVÁNY IGÉNYLÉS Felhasználói kézikönyv Dokumentum állapota: Tervezet Verzió: 0.1.0 Tartalomjegyzék 1. Bevezetés... 3 2. Bejelentkezés...

Részletesebben

HRdoc+ Rendszerismertető. Számítástechnikai és Szolgáltató Kft. Tel.: +36 23 311 799 info@divicon.hu www.divicon.hu H-2051 Biatorbágy, Viola u. 38.

HRdoc+ Rendszerismertető. Számítástechnikai és Szolgáltató Kft. Tel.: +36 23 311 799 info@divicon.hu www.divicon.hu H-2051 Biatorbágy, Viola u. 38. HRdoc+ Rendszerismertető Számítástechnikai és Szolgáltató Kft. Tel.: +36 23 311 799 info@divicon.hu www.divicon.hu H-2051 Biatorbágy, Viola u. 38. Tartalomjegyzék 1. A rendszer célja 2 2. A rendszer fő

Részletesebben

Kalumet Számlázó. Termék leírás

Kalumet Számlázó. Termék leírás Kalumet Számlázó Termék leírás Rendszerünk potenciális felhasználói Olyan vállalkozások, akiknél fontos cél, szempont, ügyfeleik kiemelt szintű kiszolgálása. Akik szeretnék, hogy a tevékenységeik, ügyfél

Részletesebben

StartÜzlet online számlázó modul Használati Útmutató

StartÜzlet online számlázó modul Használati Útmutató StartÜzlet online számlázó modul Használati Útmutató 1 Tartalomjegyzék Alapvető tudnivalók...3 Használatba vétel előtt megadandó és ellenőrizendő adatok...3 Alanyi adómentes vállalkozás esetén...3 Számla

Részletesebben

DIGITÁLIS TANÚSÍTVÁNY HASZNÁLATA A REGIONÁLIS BOOKING PLATFORMON

DIGITÁLIS TANÚSÍTVÁNY HASZNÁLATA A REGIONÁLIS BOOKING PLATFORMON DIGITÁLIS TANÚSÍTVÁNY HASZNÁLATA A REGIONÁLIS BOOKING PLATFORMON 2013. 10. 09 Készítette: FGSZ Zrt. Informatika és Hírközlés Informatikai Szolgáltatások Folyamatirányítás Az FGSZ Zrt. elkötelezett az informatikai

Részletesebben

ColourSMS Protokol definíció. Version 1.2

ColourSMS Protokol definíció. Version 1.2 ColourSMS Protokol definíció Version 1.2 1.1 HTTP request A ColourSMS(Westel/Pannon) alkalmazások által kiadott HTTP request formátuma a következő: http://third_party_url/path_to_application A third_party_url

Részletesebben

OZEKI Phone System. A jövő vállalati telefon rendszerének 4 alappillére. A jövő üzleti telefon rendszere SMS. Mobil mellékek. Összhang az IT-vel

OZEKI Phone System. A jövő vállalati telefon rendszerének 4 alappillére. A jövő üzleti telefon rendszere SMS. Mobil mellékek. Összhang az IT-vel A jövő üzleti telefon rendszere A jövő vállalati telefon rendszerének 4 alappillére SMS Mobil mellékek Webtelefon Üzenetküldés Összhang az IT-vel É rdemes elolvasni! Ajánlatkérés Kérem, töltse ki az űrlapot,

Részletesebben

Visual C++ osztály készítése, adattagok, és metódusok, láthatóság, konstruktor, destruktor. Objektum létrehozása, használata, öröklés.

Visual C++ osztály készítése, adattagok, és metódusok, láthatóság, konstruktor, destruktor. Objektum létrehozása, használata, öröklés. Visual C++ osztály készítése, adattagok, és metódusok, láthatóság, konstruktor, destruktor. Objektum létrehozása, használata, öröklés. Az osztály egy olyan típus leíró struktúra, amely tartalmaz adattagokat

Részletesebben

ENTERPRISE PORTAL. Egy modern portál esetén

ENTERPRISE PORTAL. Egy modern portál esetén ENTERPRISE PORTAL ENTERPRISE PORTAL OpenSource eszközök alkalmazásával robosztus, költséghatékony web portálok kialakítására van lehetőség. Igény esetén piacvezető, licenc díjas termékek is alkalmazhatók.

Részletesebben

INFORMATIKAI ALAPISMERETEK

INFORMATIKAI ALAPISMERETEK ÉRETTSÉGI VIZSGA 2005. május 20. INFORMATIKAI ALAPISMERETEK KÖZÉPSZINTŰ ÉRETTSÉGI VIZSGA Az írásbeli vizsga időtartama: 180 perc JAVÍTÁSI-ÉRTÉKELÉSI ÚTMUTATÓ OKTATÁSI MINISZTÉRIUM Megoldási útmutató I.

Részletesebben

A webhelyhez kötődő szoftverek architektúrája

A webhelyhez kötődő szoftverek architektúrája A webhelyhez kötődő szoftverek architektúrája A webhelyhez kötődő szoftverek architektúrája...1 A kliens-szerver funkcionalitások megoszlása...1 A böngésző mint web kliens...1 Web szerver (kiszolgáló)

Részletesebben

Általános e-mail fiók beállítási útmutató

Általános e-mail fiók beállítási útmutató Általános e-mail fiók beállítási útmutató Ennek az összeállításnak az a célja, hogy segítséget nyújtsunk azon Ügyfeleink számára, akik az IntroWeb Kft. által nyújtott e-mail szolgáltatáshoz be szeretnék

Részletesebben

Szolgáltatás Orientált Architektúra a MAVIR-nál

Szolgáltatás Orientált Architektúra a MAVIR-nál Szolgáltatás Orientált Architektúra a MAVIR-nál Sajner Zsuzsanna Accenture Sztráda Gyula MAVIR ZRt. FIO 2009. szeptember 10. Tartalomjegyzék 2 Mi a Szolgáltatás Orientált Architektúra? A SOA bevezetés

Részletesebben

EgroupWare: A csoportmunka megoldás

EgroupWare: A csoportmunka megoldás EgroupWare: A csoportmunka megoldás Bemutatás Az egroupware egy üzleti szintű, PHP alapú, szabad csoportmunka szerver megoldás, a Stylite AG terméke. A közösségi verzió szabadon letölthető és ingyenesen

Részletesebben

Üzleti interoperabilitás. - elektronikus üzleti szolgáltatások - elektronikus kereskedelem - elektronikus közbeszerzés

Üzleti interoperabilitás. - elektronikus üzleti szolgáltatások - elektronikus kereskedelem - elektronikus közbeszerzés Üzleti interoperabilitás - elektronikus üzleti szolgáltatások - elektronikus kereskedelem - elektronikus közbeszerzés Business Interoperability Interface Ország független elvárások Opcionális PEPPOL/BII

Részletesebben

Cikktípusok készítése a Xarayában

Cikktípusok készítése a Xarayában Cikktípusok készítése a Xarayában A Xaraya legfontosabb tulajdonsága az egyedi cikktípusok egyszerű készítésének lehetősége. Ezzel kiküszöbölhető egyedi modulok készítése, hiszen néhány kattintással tetszőleges

Részletesebben

ELEKTRONIKUS MUNKABÉRJEGYZÉK MODUL

ELEKTRONIKUS MUNKABÉRJEGYZÉK MODUL ELEKTRONIKUS MUNKABÉRJEGYZÉK MODUL nexonbér elektronikus munkabérjegyzék modul Kiszámolta már valaha, hogy mennyibe kerül egyetlen munkavállaló egyetlen havi munkabérjegyzéke (a nyomtatás, a borítékolás

Részletesebben

Magas szintű adatmodellek Egyed/kapcsolat modell I.

Magas szintű adatmodellek Egyed/kapcsolat modell I. Magas szintű adatmodellek Egyed/kapcsolat modell I. Ullman-Widom: Adatbázisrendszerek. Alapvetés. 4.fejezet Magas szintű adatmodellek (4.1-4.3.fej.) (köv.héten folyt.köv. 4.4-4.6.fej.) Az adatbázis modellezés

Részletesebben

Tisztelt Ügyfelünk! Tájékoztató az átállásról

Tisztelt Ügyfelünk! Tájékoztató az átállásról OTP BANK NYRT. Tisztelt Ügyfelünk! Tájékoztató az átállásról Bankunk ügyfeleink folytonos szoftverhasználatát biztosító szempont alapján úgy döntött, hogy az új verziót (6.01-01) most nem a megszokott

Részletesebben

vbar (Vemsoft banki BAR rendszer)

vbar (Vemsoft banki BAR rendszer) vbar (Vemsoft banki BAR rendszer) BAR bemutatása 1994. július 1-jétől kezdte meg működését a Központi Adós- és Hitelinformációs Rendszer, azóta is használt rövidített nevén a BAR, amely kezdetben kizárólag

Részletesebben

2. Számlainformációk (a kiválasztott számlához kapcsolódó lekérdezések)

2. Számlainformációk (a kiválasztott számlához kapcsolódó lekérdezések) A DigiBank alkalmazás funkciói lehetõvé teszik a banki ügyfelek számára, hogy a számláikról, illetve egyéb banki tevékenységükrõl, az interneten keresztül a világháló bármely pontján aktuális információkat

Részletesebben

Pilot projekt az NFGM-ben: nyílt forráskódú kollaborációs dokumentumportál és üzleti dashboard projektek tapasztalatai

Pilot projekt az NFGM-ben: nyílt forráskódú kollaborációs dokumentumportál és üzleti dashboard projektek tapasztalatai Pilot projekt az NFGM-ben: nyílt forráskódú kollaborációs dokumentumportál és üzleti dashboard projektek tapasztalatai Török Tamás Szántó Iván torok.tamas@ulx.hu szanto.ivan@ulx.hu ULX Open Source Consulting

Részletesebben

Telepítési útmutató. web: www.szakk.hu e-mail: info@szakk.hu

Telepítési útmutató. web: www.szakk.hu e-mail: info@szakk.hu Telepítési útmutató web: www.szakk.hu e-mail: info@szakk.hu Tartalomjegyzék: Telepítési útmutató... 1 Tartalomjegyzék:... 2 Első lépések:... 3 Konzol oldal telepítése... 3 Licenc megállapodás... 3 Telepítési

Részletesebben

GeoServer, OpenLayers és WFS. Dolleschall János 2009. 08. 17.

GeoServer, OpenLayers és WFS. Dolleschall János 2009. 08. 17. GeoServer, OpenLayers és WFS Dolleschall János 2009. 08. 17. A GeoServer A GeoServer egy nyílt forráskódú szerver szoftver, ami lehetővé teszi térbeli adatok megosztását. Java-ban íródott, így platformfüggetlen.

Részletesebben

PRECÍZ Információs füzetek

PRECÍZ Információs füzetek PRECÍZ Információs füzetek Információk, Módszerek, Ötletek és Megoldások a Precíz Integrált Ügyviteli Információs rendszerhez T14. ODBC adatkapcsolat 2009. augusztus 31. PRECÍZ integrált ügyviteli rendszer

Részletesebben

A CAPICOM ActiveX komponens telepítésének és használatának leírása Windows 7 operációs rendszer és Internet Explorer 9 verziójú böngésző esetén

A CAPICOM ActiveX komponens telepítésének és használatának leírása Windows 7 operációs rendszer és Internet Explorer 9 verziójú böngésző esetén A CAPICOM ActiveX komponens telepítésének és használatának leírása Windows 7 operációs rendszer és Internet Explorer 9 verziójú böngésző esetén Tartalomjegyzék 1. Az Internet Explorer 9 megfelelősségének

Részletesebben

Közösség, projektek, IDE

Közösség, projektek, IDE Eclipse Közösség, projektek, IDE Eclipse egy nyílt forráskódú (open source) projekteken dolgozó közösség, céljuk egy kiterjeszthető fejlesztői platform és keretrendszer fejlesztése, amely megoldásokkal

Részletesebben

Hiba bejelentés azonnal a helyszínről elvégezhető. Egységes bejelentési forma jön létre Követhető, dokumentált folyamat. Regisztráció.

Hiba bejelentés azonnal a helyszínről elvégezhető. Egységes bejelentési forma jön létre Követhető, dokumentált folyamat. Regisztráció. Ingyenes Mobil helpdesk megoldás A Mobil helpdesk egy olyan androidos felületen futó hibabejelentő, amelynek néhány alapbeállítását megadva saját mobil hibabejelentő rendszere lehet, vagy partnereinek

Részletesebben

Visual Studio 2012 és MSDN. Csomagok és licencelés

Visual Studio 2012 és MSDN. Csomagok és licencelés Visual Studio 2012 és MSDN Csomagok és licencelés Karácsony Sándor Ker-Soft Számítástechnikai Kft. Licencelési alap: Fejlesztőeszközök - felhasználói licenc Licenccel rendelkező felhasználó Minden beszerzett

Részletesebben

OZEKI Phone System. 4 elengedhetetlen szolgáltatás a jövőbeli vállalati telefonos rendszerek számára. A jövő üzleti telefon rendszere SMS

OZEKI Phone System. 4 elengedhetetlen szolgáltatás a jövőbeli vállalati telefonos rendszerek számára. A jövő üzleti telefon rendszere SMS A jövő üzleti telefon rendszere 4 elengedhetetlen szolgáltatás a jövőbeli vállalati telefonos rendszerek számára SMS Mobil mellékek Webtelefon Üzenetküldés és jelenlét Összhang az IT-vel Olvassa el! Ajánlatkérő

Részletesebben

2. előadás. Radio Frequency IDentification (RFID)

2. előadás. Radio Frequency IDentification (RFID) 2. előadás Radio Frequency IDentification (RFID) 1 Mi is az az RFID? Azonosításhoz és adatközléshez használt technológia RFID tag-ek csoportosítása: Működési frekvencia alapján: LF (Low Frequency): 125

Részletesebben

Erőforrás gazdálkodás a bevetésirányításban

Erőforrás gazdálkodás a bevetésirányításban Professzionális Mobiltávközlési Nap 2009 Új utakon az EDR Erőforrás gazdálkodás a bevetésirányításban Fornax ZRt. Nagy Zoltán Vezérigazgató helyettes Budapest, 2009. április 9. Tartalom 1. Kézzelfogható

Részletesebben

Melyek a Windows Server 2008 R2 tiszta telepítésének (Clean Install) legfontosabb lépései?

Melyek a Windows Server 2008 R2 tiszta telepítésének (Clean Install) legfontosabb lépései? Mely Windows Server 2008 R2 kiadásra jellemzőek a következők: Maximum 32GB RAM és 4 CPU foglalatot, valamint 250 RRAS, 50 IAS és 250 RDS-GW licenszet nyújt? Web Standard Enterprise Datacenter Melyek a

Részletesebben

BaBér bérügyviteli rendszer telepítési segédlete 2011. év

BaBér bérügyviteli rendszer telepítési segédlete 2011. év BaBér bérügyviteli rendszer telepítési segédlete 2011. év Ajánlott konfiguráció A program hardverigénye: Konfiguráció: 2800 MHz processzor 512 Mbyte memória (RAM) / Szerver gépen 1G memória (RAM) Lézernyomtató

Részletesebben

INFORMATIKAI ALAPISMERETEK

INFORMATIKAI ALAPISMERETEK Informatikai alapismeretek középszint 0621 ÉRETTSÉGI VIZSGA 2007. május 25. INFORMATIKAI ALAPISMERETEK KÖZÉPSZINTŰ ÍRÁSBELI ÉRETTSÉGI VIZSGA JAVÍTÁSI-ÉRTÉKELÉSI ÚTMUTATÓ OKTATÁSI ÉS KULTURÁLIS MINISZTÉRIUM

Részletesebben

Testreszabott alkalmazások fejlesztése Notes és Quickr környezetben

Testreszabott alkalmazások fejlesztése Notes és Quickr környezetben Testreszabott alkalmazások fejlesztése Notes és Quickr környezetben Szabó János Lotus Brand Manager IBM Magyarországi Kft. 1 Testreszabott alkalmazások fejlesztése Lotus Notes és Quickr környezetben 2

Részletesebben

Tartalomjegyzék 2. RENDSZER FELÉPÍTÉSE... 3

Tartalomjegyzék 2. RENDSZER FELÉPÍTÉSE... 3 Tartalomjegyzék 1. BEVEZETŐ... 2 2. RENDSZER FELÉPÍTÉSE... 3 2.1. FELÜLET... 3 2.2. FELHASZNÁLÓI FUNKCIÓK... 4 2.2.1. Modulok... 4 2.2.2. Előzmények... 4 2.2.3. Lekérdezés működése, beállítások... 5 2.2.4.

Részletesebben

GIS fejlesztés Web platformra nyílt forráskódú ingyenes eszközökkel

GIS fejlesztés Web platformra nyílt forráskódú ingyenes eszközökkel Nyugat-Magyarországi Egyetem Geoinformatikai Kar Magyar Tudomány Ünnepe 2007 A térinformatika mindenkié GIS fejlesztés Web platformra nyílt forráskódú ingyenes eszközökkel Kottyán László adjunktus Tartalom

Részletesebben

Adatbázis rendszerek 6.. 6. 1.1. Definíciók:

Adatbázis rendszerek 6.. 6. 1.1. Definíciók: Adatbázis Rendszerek Budapesti Műszaki és Gazdaságtudományi Egyetem Fotogrammetria és Térinformatika 6.1. Egyed relációs modell lényegi jellemzői 6.2. Egyed relációs ábrázolás 6.3. Az egyedtípus 6.4. A

Részletesebben

Az összes szolgáltatás együttes megrendelése esetén a kedvezményes végösszeg:

Az összes szolgáltatás együttes megrendelése esetén a kedvezményes végösszeg: NETTESZT Informatikai Kft. Számlázási és postai cím: 2013 Pomáz, Deák Ferenc utca 2. Tel.: +36-1-445-0999 Fax: +36-1-445-0998 E-mail:info@netteszt.hu Bankszámlaszám: 10403057-50526565-90851007 Keresőoptimalizálás

Részletesebben

Metadata specifikáció

Metadata specifikáció Metadata specifikáció Verzió: 1.1 (2011. Szeptember 14.) aai@niif.hu Biztonsági megfontolások Mivel a metadata tartalmazza a föderációban részt vevő tagok és komponensek technikai információit, ezért a

Részletesebben

ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu

ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu Számonkérés 2 Papíros (90 perces) zh az utolsó gyakorlaton. Segédanyag nem használható Tematika 1. félév 3 Óra Dátum Gyakorlat 1. 2010.09.28.

Részletesebben

Dr. Sipos Marianna ZMNE BJKMK

Dr. Sipos Marianna ZMNE BJKMK Dr. Sipos Marianna ZMNE BJKMK Tömeges felhasználás Eredeti cél: Desctop alkalmazások mindenkinek Egyedi géphasználat Kényelmes, felhasználóbarát felület Mit áldoztak fel: Hozzáférés szabályozás minimális

Részletesebben

Telepítési és indítási útmutató. DataPage+ 2013

Telepítési és indítási útmutató. DataPage+ 2013 DataPage+ 2013 Tartalomjegyzék Telepítés előfeltételei Alkotólemek... 1 Áttekintés... 1 1. lépés: Futtassuk a setup.exe fájlt és indítsuk el a varázslót... 1 2. lépés: Fogadjuk el a licencszerződést...

Részletesebben

Szoftvertechnolo gia gyakorlat

Szoftvertechnolo gia gyakorlat Szoftvertechnolo gia gyakorlat Dr. Johanyák Zsolt Csaba http://johanyak.hu 1. Dependency Injection (függőség befecskendezés) tervezési minta A tervezési minta alapgondolata az, hogy egy konkrét feladatot

Részletesebben