SOA-alapú rendszerintegráció forrásának megtekintése

{{GlobalTemplate|Valaszthato|SoaAlapuRendszerintegracio}}


__TOC__

==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 &ndash; moduláris építkezés már létezik
* Megoldás módszere
** fokozatosan bővülő rendszer &ndash; 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====

{| border="1"
| '''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====

{| border="1"
| ** || '''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====
* [http://en.wikipedia.org/wiki/Message_Transmission_Optimization_Mechanism 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: [http://en.wikipedia.org/wiki/Kerberos_(protocol) Kerberos])
* WS-Federation: trusted domain-eken túli azonosítás, single sign-on

====Megbízható üzenetküldés====
* analógia: [http://en.wikipedia.org/wiki/Transmission_Control_Protocol 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, [http://en.wikipedia.org/wiki/Two-phase_commit_protocol 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: [http://jax-ws.java.net/ [[GlassFish]] ESB] (referencia implementáció)
* [http://cxf.apache.org/ 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&lt;T>, Set&lt;T>, SortedSet&lt;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): [http://jersey.java.net/ Jersey]
* JBoss: [http://www.jboss.org/resteasy RESTeasy]
* [http://cxf.apache.org/ Apache CXF]
* [http://www.restlet.org/ 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 &ndash; 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 &#8211; nem módszertan

http://zachmaninternational.com/2/production/C4/images/Zachman_Framework.jpg

=====TOGAF &ndash; 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 &#8211; 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 &ndash; 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 &#8211; Architektúra &#8211; 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&#8217;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 &#8211; 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=====
http://zeetalks.files.wordpress.com/2009/07/soa-maturitymodel.jpg

=====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

-- [[VeresSzentkiralyiAndras|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&#44; Ercsényi András&#44; 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=""}%

[[Category:Valaszthato]]