SOA-alapú rendszerintegráció

Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata itt érhető el.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor kérlek javíts rajta egy rövid szerkesztéssel.

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót

Hivatalos weboldal

https://www.iit.bme.hu/~soarinteg/

Tárgykövetelmény

• szorgalmi időszakban: egy, az előadáson egyénileg kiosztott házi feladat megoldása (valamilyen SOA feladat implementálása JAX-WS alapokon + dokumentáció)
• vizsgaidőszakban: szóbeli vizsga az alábbi tételsor alapján

Tételsor

Ismertesse az integrált szolgáltatások kialakításának tipikus követelményeit!

Forrás: https://www.iit.bme.hu/~soarinteg/Eloadas1.pdf

Bővíthetőség

• A rendszer gazdaságosan új funkciókkal bővíthető
• Meglévő funkcionalitások kiterjeszthetők ezek korlátozása nélkül
• Pl. jogszabályok folyamatos változása miatt

Rugalmasság

• A kialakított architektúra topológiájának tulajdonsága
• A rugalmasság annak a mértéke, hogy az architektúrát új nemfunkcionális követelmények megjelenése esetén milyen könnyen lehet módosítani
• A rugalmas topológia elősegíti a gyors változtathatóságot, ezzel javítva a rendelkezésre állást, megbízhatóságot és skálázhatóságot.

Interoperabilitás

• Az interoperabilitás az együttműködési képességet jelenti
• Heterogén szoftverrendszerekkel rendelkező szereplők kommunikációképessége
• Függetlenül a szoftvergyártóktól és a felhasznált alsóbb protokolloktól
• Szintjei:
  • szintaktikai: megfelelő protokollok megválasztása, adatformátumok egyeztetése
  • szemantikai: ugyanazt kell érteni az adatok jelentésén
  • intézményi: az egyes szakrendszerek egymással szakmailag és politikailag is tudnak tárgyalni és meg tudnak egyezni

Nyitottság

A nyitottság azt jelenti, hogy meglévő és új szereplők minél kisebb költséggel integrálhatók a teljes rendszerbe. Ehhez jól definiált interfészekre van szükség.

Újrahasznosíthatóság

Bizonyos komponensek vagy szolgáltatások azonos vagy hasonló feladatok megoldása során is felhasználhatók legyenek, ezáltal elkerülhető a redundáns fejlesztés.

Különböző absztrakciós szinteken történhet, pl.:

• közös adat- és folyamatmodellek
• közös architektúraminták
• központosított szolgáltatások

Biztonság

• Az információkat csak a kialakított biztonságpolitikának megfelelően lehet megszerezni vagy módosítani.
• A legfontosabb szempontok: azonosítás, hitelesítés, felhatalmazás, titkosság, sértetlenség és letagadhatatlanság

Teljesítmény

A teljesítmény azt jelenti, hogy a rendszer funkcionalitását elég gyorsan végre lehet hajtani ahhoz, hogy a használhatóság biztosítva legyen. Mértéke az időegység alatt kiszolgált kérések száma.

Skálázhatóság

A skálázhatóság azt jelenti, hogy a rendszer növekvő terhelés mellett is képes a kívánt hatékonyságot és teljesítményt biztosítani. Ehhez biztosítani kell új erőforrások problémamentes bevonását.

Rendelkezésre állás

A rendelkezésre állás annak a mértéke, hogy a rendszer milyen módon képes a funkcionalitását, szolgáltatásait és erőforrásait kiesésmentesen biztosítani.

Megbízhatóság

A rendszer hálózati problémák vagy bizonyos komponensek kiesése esetén is képes a kérések fogadására. A befogadott kérések nem veszhetnek el, azoknak előbb-utóbb meg kell érkeznie.

Karbantarthatóság

A rendszer komolyabb előképzettség nélkül olyan külső szereplők által is gazdaságosan működtethető, akik a rendszer kifejlesztésében nem vettek részt.

Ismertesse az integrált szolgáltatások kialakulásának folyamatát!

Forrás: https://www.iit.bme.hu/~soarinteg/Eloadas2.pdf

Monolit rendszerek

• Régebbi rendszerfejlesztési filozófia
  • fokozatosan bővülő igények
  • gyors válaszok szükségesek – moduláris építkezés már létezik
• Megoldás módszere
  • fokozatosan bővülő rendszer – méret egyre nehezebben kezelhető
  • célzottan csak az adott alkalmazáshoz
    • nincs újrafelhasználhatóság
    • újrafelhasználás helyett ismételt megvalósítás
    • duplikátumok miatt hibajavítás nehézségek
  • modularizálható, de ettől még nem újrafelhasználható

Önálló szolgáltatások

• Az alkalmazás modulárisan készül, szolgáltatásokból, egyedi összekötéssel.
• Így egy új alkalmazás önálló modulokból, egyedi megoldással, más kapcsolati sémában, újrafelhasználható módon készíthető el.
• Együttműködési problémák:
  • Különböző programnyelvek
  • Különböző operációs rendszerek
  • Különböző adatreprezentációk
  • Különböző gyártók
  • Alkalmazások együttműködése

Szolgáltatásorientált architektúra

• A SOA szolgáltatások halmaza, amelyek kommunikálnak egymással és/vagy szolgáltatásokat ajánlanak fel a külvilágnak.
• A szolgáltatás architekturális alapegység, mely jól definiált, önálló, újrahasználható, más hasonló rendszerektől független rendszer.
• Az ezek közti kommunikáció legtöbbször web-service, mely request-response jellegű (service használó (consumer) küld egy request-et, service szolgáltató (producer) visszaküld egy választ), XML bázisú, RPC alapú, internetet (legtöbbször HTTP-t) használó technológia.

Követelmények

egyszerű	bonyolult lett
szabványos	majdnem
*nyelvfüggetlen*	sikerült
op.rendszer független	sikerült
gyors	viszonylag lassú lett
szélesen támogatott	sikerült

Ismertesse a SOAP és a WSDL felépítését!

Forrás: https://www.iit.bme.hu/~soarinteg/Eloadas3.pdf

SOAP

• 1998-ban találta ki a Microsoft Simple Object Access Protocol néven
• ma a W3C gondozza, két elterjedt verziója az 1.1 és az 1.2
• alkalmazások közti, platform- és programnyelvfüggetlen, XML-re épülő kiterjeszthető kommunikációs protokoll
• általában HTTP felett alkalmazzák
  • SOAP 1.1 text/xml Content-Type-ot használ, a hívás neve SOAPAction HTTP fejlécben kerül megadásra
  • SOAP 1.2 application/soap+xml Content-Type-ot használ, melynek action paraméterében kerül a hívás neve megadásra

WSDL

• W3C által gondozott web-szolgáltatás leíró nyelv (Web Services Description Language)
• használt verziói az 1.1 és a 2.0 (utóbbi még nem szabvány, csak ajánlás)
• tartalmazza az interfészeket, metaadatokat és a szolgáltatások címeit

Message Exchange Patternek

**	van output	nincs input
van input	request-reply	one-way (aszinkron)
nincs input	solicit-response	-

Ismertesse a tanult WS-* szabványokat (hatékony bináris átvitel, biztonság, megbízható üzenetküldés, tranzakciók, metaadatok)!

Forrás: https://www.iit.bme.hu/~soarinteg/Eloadas56.pdf

Hatékony bináris átvitel

• MTOM: Messaging része, bináris adatok küldését teszi lehetővé byte-folyamként külön MIME részben

Biztonság

• WS-Security: tiktosítás, digitális aláírás
• WS-SecureConversation: szimmetrikus kulcs generálása, titkosított adatcsere (analógia: SSL)
• WS-Trust: tokenek kérése, kibocsátása (analógia: Kerberos)
• WS-Federation: trusted domain-eken túli azonosítás, single sign-on

Megbízható üzenetküldés

• analógia: TCP
• WS-Reliability: eredeti változat, nem veszi figyelembe a többi protokollt
• WS-ReliableMessaging: jobban támogatott, figyelembe veszi a többi protokollt is (pl. transactions, security, ...)

Tranzakciók

• WS-Coordination: tranzakció levezénylése
• WS-AtomicTransaction: rövid lejáratú tranzakciók, 2PC
• WS-BusinessActivity: hosszú lejáratú tranzakciók, rollback esetén kompenzáció

Metaadatok

• WS-Policy: egy szolgáltatás képességeit és követelményeit írja le, ezzel kibővíti a WSDL leírást, pl. WS-Security Policy, WS-ReliableMessaging Policy, WS-AtomicTransaction Policy
• WS-MetadataExchange: WSDL dokumentumok felderítése, Policy-információk cseréje dinamikus protokollfelismeréshez

Ismertesse webszolgáltatások stílusjegyeit és fejlesztési metódusait!

Forrás: https://www.iit.bme.hu/~soarinteg/Eloadas4.pdf

Stílusjegyek

WSDL típus

• WSDL 1.1: elterjedt, támogatott, ajánlott
• WSDL 2.0: előnyösebb tulajdonságokkal rendelkezik, nem terjedt el

SOAP verzió

• alapvetően mindkettő ajánlott
• SOAP 1.1: JAX-WS alapból támogatja
• SOAP 1.2: kicsit előnyösebb

WS stílus

• JAX-RPC: Java-RMI webszolgáltatások felett, RPC stílus, egyre jobban kiszorul, de még elterjedt
• JAX-WS: JAX-RPC 2.0, újabb, document stílus, optimálisabb megoldás, ahol csak lehet, érdemesebb ezt használni

Kötési (binding) stílus

• RPC
  • /encoded: egyszerű a WSDL, első stílus volt, nem WS-I compliant
  • /literal: egyszerű a WSDL, WS-I compliant, problémás a validálás
• Document
  • /encoded: valójában nem is létezett
  • /literal: bonyolultabb a WSDL és a SOAP-XML, jól validálható, nem WS-I compliant
  • /literal wrapped: bonyolult WSDL, literalhoz hasonló SOAP-XML, jól validálható, WS-I compliant

Javaslat: Document/literal wrapped (néha csak literal néven ismert), mert jó a leírás és a modell, könnyen validálható, cserébe a szerkezet bonyolult és nem használható overload-nál

Adat típus menedzselés (+ szeparábilitás)

• WSDL-en kívüli types: külön fejleszthető, újrafelhasználható, bővíthető, WSDL módosítása nélkül szerkeszthető, kisebb és átláthatóbb a WSDL, így ez ajánlott
• WSDL-en belüli types

Paraméter-csomagolás

• külön-külön primitív paraméterek
• egy-egy összetett be- és kimeneti paraméter: ez ajánlott, mivel a sok paraméter kezelése nehézkes, a megoldás így egyszerűbb

Típusosság

• erősen típusos WS (xsd:{pattern,restriction,enumeration,sequence}s): jól definiált interface, belépő adatok ellenőrizhetők, cserébe XML schemában profizmus szükséges és az adatmodell nehezen változtatható, éles környezetbe ajánlott
• lazán típusos WS: flexibilis, könnyű a fejlesztés, cserébe az interface nem teljesen definiált, WS szinten nem ellenőrizhető, fejlesztéshez ajánlott

Fejlesztési metódusok

WS készítés módszerei

• {implementation,code}-first, bottom-up: egyszerű, cserébe a WSDL lazán típusos lesz, egyszerűbb esetben ajánlott
• {schema,WSDL}-first, top-down, contract-{base,driven}: nehézkes, cserébe a WSDL pont annyira típusos, amennyire a fejlesztő szeretné, interoperabilitás céljából célszerű, ipari alkalmazásnál ajánlott

Programírás módszerei

• annotációval: legalább Java 5.x kell, ha lehet, ezt ajánlott használni, egyre terjed
• annotáció nélkül: minden utasítást kódolni kell

Ismertesse az XML alapú digitális aláírást és titkosítást!

Forrás: https://www.iit.bme.hu/~soarinteg/Eloadas56.pdf

Digitális aláírás

1 aláírandó erőforrások meghatározása 1 opcionális transzformációk (pl. binárist base64-elünk, XML-re XSLT) 1 hash (message digest) készítés: SHA1, SHA256, SHA512 1 referenciák összegyűjtése (SignedInfo, ez lesz aláírva), kanonizációs és aláíró algoritmus választása 1 kanonizálás (SignedInfo): whitespace, egyértelműség 1 aláírás: kanonizált, hasheket tartalmazó SignedInfo SHA1-ét RSA-val vagy DSA-val aláírják 1 kulcsinformációk hozzáadása (opcionális) 1 objektuminformációk hozzáadása (pl. időbélyeg) 1 elemek összesítése

Titkosítás

1 Titkosító algoritmus kiválasztása (3DES, AES-{128,192,256)) 1 Kulcs kiválasztása/megszerzése (előre megosztott vagy kulcscsere) 1 Titkosítandó adat kiválasztása (XML elem, annak tartalma, más adat, kulcs) 1 Titkosítás 1 Kulcsinformációk hozzáadása 1 Összesítés 1 Titkosítatlan adat lecserélése titkosítottra

Ismertesse a REST technológia alapelveit és kritikáit!

Forrás: https://www.iit.bme.hu/~soarinteg/Eloadas7.pdf

Alapelvek

• Minden erőforráshoz azonosító rendelése: URN, de inkább URL
• Dolgok összekapcsolása: jó URL címek továbbadhatók, utólag betölthetők
• CRUD műveletek használata: safe, idempotens
• Többféle adatreprezentáció: kiterjesztés, de inkább Accept fejléc
• Állapotmentes kommunikáció: skálázható, újraindítható

Kritikák

• CRUD műveleteken kívül másra nem alkalmas: pedig de: GET paraméterek, POST + redirect
• Nincs interfészleíró: pedig van: szöveges leírás, WADL, WSDL 2.0
• Túl sok belső részletet elárul: pedig csak a szemlélet más (művelet- helyett adatközpontú)
• Tervezési guideline-ok hiánya: ellenben józan ész és tapasztalat segít
• Middleware funkciók hiánya: nincs tranzakciókezelés, megbízható üzenetküldés
• Nincs publish-subscribe ill. aszinkron kommunikáció: pedig de: publish-subscribe (RSS, notification-by-polling), HTTP 202 Accepted

Ismertesse a JAX-WS és a JAX-RS technológiákat! Milyen keretrendszerek implementálják ezeket?

JAX-WS

Forrás: https://www.iit.bme.hu/~soarinteg/Eloadas3.pdf

• JAX-WS: Java API for XML-based Web-Services
• Web-szolgáltatások egyszerű implementálása, WSDL és Java osztályok közti leképzés annotációkkal
• kliens generálható =wsimport= eszközzel

Fontosabb implementációk

• Sun: GlassFish ESB (referencia implementáció)
• Apache CXF

JAX-RS

Forrás: https://www.iit.bme.hu/~soarinteg/Eloadas7.pdf

• JAX-RS: Java API for RESTful Web Services (JSR-311)
• Java osztályok leképzése REST erőforrásokra Java annotációk segítségével
• Paraméter annotációk: =@{Path,Query,Matrix,Form,Cookie,Header}Param=
• Támogatott típusok:

1 primitív típusok 1 olyan =T= típusok, amelyeknek van egy darab =String= paraméterrel rendelkező konstruktoruk 1 olyan =T= típusok, amelyek statikus függvényként tartalmazzák a következő szignatúrájú metódusok valamelyikét:

• • • =public static T valueOf(String)=
    • =public static T fromString(String)=

1 =List<T>, Set<T>, SortedSet<T>,= ahol =T= a fenti 2-es vagy 3-as esetből kerül ki

• JAXB technológiával egységesen kezelhető az XML és JSON kimenet
• kliensre nem vonatkozik

Fontosabb implementációk

• hivatalos (Sun-Oracle): Jersey
• JBoss: RESTeasy
• Apache CXF
• Restlet

Ismertesse a BPMN és a BPEL szabványokat!

Forrás: https://www.iit.bme.hu/~soarinteg/Eloadas910.pdf

Business Process Modeling Notation (BPMN)

• OMG szabvány, grafikus modellező nyelv üzleti folyamatok leírására
• Nincs formális reprezentációja, de törekednek az XML szintű leírásra (adatcsere céljából): XPDL (XML Process Definition Language)
• Alkalmas több szereplő modellezésére, choreography
• Célja a grafikus leíráson keresztül a folyamatok jobb megértése, ábrázolása, végrehajtható kód előállítására való alkalmassá tétele
• Részei:
  • Participants: bármely szereplő, aki részt vesz a folyamatban, lehet: system, human, process
  • Activities: tevékenység, tovább bontható, atomi egység a task, lehet manuális vagy automatizált
  • Events: esemény: üzenet, időzítő, hiba, visszavonás, kompenzáció, szabály, link, terminálás, többszörözés
  • Gateways: elágazás és bevárás (fork/join), lehet XOR, OR, komplex döntés, párhuzamos futás
  • Connections: vezérlés, adat, asszociáció
  • Artifacts: egyéb rajzi jelölések: adat, szöveges megjegyzés, csoport

Business Process Execution Language (BPEL)

• OASIS szabvány, XML alapú végrehajtható nyelv, mely webszolgáltatásokra épül
• Üzleti folyamatokat ír le, biztosít és felhasznál webszolgáltatásokat
• Orchestrationre ad lehetőséget
• BPEL folyamat leírja a végrehajtás műveleteinek (webszolgáltatás hívások) sorrendjét, a webszolgáltatások között megosztott adatot, a folyamatban résztvevő partnereket, a kivételkezelést, és a webszolgáltatások közötti hosszú lefutású tranzakciókat
• Részei:
  • import: WSDL és XSD importálható
  • partnerLinks: Definiálja a folyamat és a partner által használt web-szolgáltatásokat, egy partnerLinkType-ra (WSDL kiterjesztés) hivatkozik, megadja a folyamat (myRole) és a partner (partnerRole) szerepét
  • variables: adatokat tárolnak, a folyamat állapotát írják le, lehetnek WSDL üzenetek, ideiglenes adatok, a folyamat ezeket perzisztensen megőrzi
  • simple activities: receive (üzenet fogadása), reply (szinkron válasz), invoke (szinkron vagy aszinkron kérés elküldése), wait (várakozás), empty (nem csinál semmit), terminate (azonnali leállítás), throw (kivétel dobása), assign (értékek másolása változók, partnerLinkek, stb. között), compensate (befejezett műveletek hatásának visszavonása)
  • structured activities: sequence (soros végrehajtás), switch/if, while, pick (messagehalmaz, ha valamelyik megérkezik, tevékenység hajtódik végre, timeout is definiálható)
  • flow: tevékenységek párhuzamos végrehajtása, irányított gráf (link) tevékenységek között, ezekhez feltétel is definiálható
  • link: vezérlés szabályozása: link státusz majd join condition kiértékelése, nem alkothatnak kört
  • scope: tevékenység viselkedési környezetet definiál: helyi változók, correlation sets, fault handlers, event handlers, compensation handlers
  • correlation set: a folyamat/scope elején megadja a korrelálandó property-k listáját, amelyeknek a futás során mind korrelálnia kell
  • fault handler: kivételt kezel, WSDL hívásként kiküldhető
  • event handler: pickhez hasonló, de futás közben fogad eseményt
  • compensation handler: rollback inverz művelettel, tipikusan WS hívás

Ismertesse az ESB technológiát!

Forrás: https://www.iit.bme.hu/~soarinteg/Eloadas11.pdf

• nincs elfogadott definíció
• felhasználói szempontból: konfigurálható, platform- és nyelvfüggetlen kapcsolat alkalmazások között
• technikai szempontból: általános és bővíthető hosting rendszer szolgáltatások és komponensek integrálásához, mely monitorozási, mérési lehetőséget biztosít
• az alkalmazások üzenetalapon, lazán kapcsolódnak
• vállalati szintű QoS, biztonság, skálázhatóság, tranzakciókezelés biztosítható
• különféle architektúrákat támogat (eseményvezérelt, publish-subscribe)
• szabványokat használ, XML-alapú: XSD, WSDL, XPath, XSLT, WS-BPEL
• bővíthető: közös belső üzenetforma, konténerek
• végpontos: átváltás protokollok és üzenetformák között
• pipeline: konfigurálható, bővíthető, dinamikus végpont kapcsolódás, értéknövelt szolgáltatások
• kapcsolat egyéb (nem WS) middleware-ekkel (J2EE, CORBA, RDBMS) és kommunikációs rendszerekkel (JDBC, JMS, SMTP, MQ)

Szabványok

• J2EE: JTA (tranzakciókezelés), JMS (üzenetkezelés)
• Enterprise: JSSE (SSL), JAAS (autentikáció), JCE (kriptográfia), JMX (menedzsment)
• JBI: Java Business Integration, céljai
  • szabványos Service Provider Interface kialakítása
  • absztrakt üzenetkezelési mechanizmus az integrációhoz
  • szabvány a csomagoláshoz és a telepítéshez
  • adminisztrációs és menedzselési előírás

Konkrét megoldások

• Gyári rendszerek: IBM, Oracle, Sun/Glassfish, OpenESB
• Közvetlen megoldás – Open Source komponensekből: Tomcat + Axis + Joram/Jetlang + Orbeon

Ismertesse a SOA projektmenedzsment keretrendszereket és a SOA érettségi modelleket!

Forrás: https://www.iit.bme.hu/~soarinteg/Eloadas12.pdf

SOA projektmenedzsment keretrendszerek

Zachman Framework

• Univerzális, rendezett gondolkodási keret két dimenzióban
  • Ki, mit, mikor, hol, hogyan, miért
  • Általánostól a különösig
• A cellákhoz tartozik leírási (ábrázolási) mód
• Cél: minden cellával foglalkozni kell
• Alkalmas tetszőleges, bonyolult rendszer rendezett leírására
• Nem írja elő a bejárási sorrendet – nem módszertan

TOGAF – The Open Group Architectural Framework

• Architektúra keretrendszer
• Fázisok egymás után, absztrakciós szint fokozatos csökkentése, fázisonként ütköztetés a követelményekkel

Gartner EA Process Model

• Gartner Group – vezető IT elemző
• Szemlélet: a jelenlegi helyzet és az elérendő közötti rés bezárása iteratív fejlesztéssel

PGFSOA – Practical Guide to Federal Service Oriented Architecture

• Mennyiben segíti a SOA az üzleti stratégiát
• Érettségi modell, érettség értékelése
• Szervezeti szinten szükséges módosítások
• Súlyponti szolgáltatások SOA-val
• Egymásra épülés: Infrastruktúra – Architektúra – Vállalkozás

BEA SOA Roadmap

• Iteratív, inkrementális fejlesztés
• Érettség, Hatókör, Minőség
• Fázisok:

1 Tervezés (hatókör, viszony más IT tervekhez, igazoló esettanulmányok, jelen és jövő üzleti folyamatai) 1 Érettség értékelése (6 terület) 1 Jövőkép (6 terület) 1 Roadmap definíció (6 terület)

• Roadmap karbantartása

ZapThink’s SOA Roadmap

• Iteratív, inkrementális
• Kulcsproblémák
  • bonyolult hozzáférni adatokhoz
  • alkalmazás régi adatbázishoz akar hozzáférni
  • teljesítménymutatók világos megjelenítése szükséges
  • folyamatok újraszervezendők
• Kísérletek
  • Érettség: szervezet, IT infrastruktúra, IT szervezet
  • Silók – elhatárolt területen
• Pilot
• Áttérés (pragmatikus szemlélettel)

Accenture Roadmap

• Iteratív
• Tervezés: igények, felkészültség, áttérés
• Pre-pilot kísérletek
• Belső rendszer szisztematikusan SOA
• Intézményközi, federatív, előrejelzések,
• csaknem real-time
• Eredmények: 2-4 év

SOA érettségi modellek

Business Process Interoperability Maturity (BPIM)

• Ötlet: Capability Maturity Model (CMM)
• Általánosan jellemző 5 terület
• 5 fokozatú érettség

1 Esetleges (silózott, ad-hoc): Helyi eredmények, együttműködés nehéz 1 Taktikai együttműködés: Van kapcsolat a szigetek között, de pont-pont, egy-egy feladat érdekében 1 Újrahasznosítás (folyamat-vezérlés): Vannak üzleti folyamatok, több folyamatban is használt szolgáltatások 1 Megosztott szolgáltatások: A szolgáltatások a középpontban, BPM 1 Szolgáltatás-orientált: Monitorozott, dinamikus szolgáltatások

Microsoft Service Oriented Architecture Maturity Model

Gartner Assessment Framework

• E-kormányzati megoldásokhoz
• 3 dimenzió

1 Idő 1 Bonyolultság/költség 1 Közösségi érték (fázisonként nőnie kell)

• Területek
  • Stratégia és eljárásrend
  • Emberi tényező
  • Folyamatok
  • Technológia

-- dnet - 2011.05.21.

%META:FORM{name="ValaszthatoForm"}% %META:FIELD{name="Trgy" title="Tárgy" value="SOA-alapú rendszerintegráció"}% %META:FIELD{name="Trgykd" title="Tárgykód" value="VIIIM371"}% %META:FIELD{name="Tanszk" title="Tanszék" value="IIT"}% %META:FIELD{name="Elad" title="Előadó" value="Dr. Kondorosi Károly, Ercsényi András, Simon Balázs"}% %META:FIELD{name="Kreditszm" title="Kreditszám" value="4"}% %META:FIELD{name="raszm" title="Óraszám" value="2/1/0/v"}% %META:FIELD{name="Flv" title="Félév" value="tavaszi"}% %META:FIELD{name="Terlet" title="Terület" value="Web"}% %META:FIELD{name="raijelenlt" title="Órai jelenlét" value="ajánlott"}% %META:FIELD{name="Jegy" title="Jegy" value="vizsga "}% %META:FIELD{name="Elvrtmin.munka" title="Elvárt min. munka" value=""}% %META:FIELD{name="Minimumrajrjegy" title="Minimumra járó jegy" value=""}% %META:FIELD{name="Elvrtmax.munka" title="Elvárt max. munka" value=""}% %META:FIELD{name="Munkrajrjegy" title="Munkára járó jegy" value=""}%