Nagyvállalati SOA infrastruktúra (ESB, szolgáltatástárak)

Hasonló dokumentumok
Szolgáltatásintegráció (VIMIM234) tárgy bevezető

Szolgáltatásorientált rendszerintegráció. SOA-alapú rendszerintegráció. Enterprise Service Bus (ESB) Ercsényi András, BME IIT, 2011.

Java Business Integration szolgáltatásalapú architektúra JavaEE környezetben. Simon Géza Zsemlye Tamás

Szolgáltatásintegráció (VIMIM234) tárgy bevezető

Oracle9i Alkalmazás Szerver Üzleti folyamat integráció. Molnár Balázs Vezető értékesítési konzultáns Oracle Hungary

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Üzleti folyamatok rugalmasabb IT támogatása. Nick Gábor András szeptember 10.

Debreceni Egyetem Informatikai Kar. Szolgáltatás-orientált programozás az Oracle-ben

Osztott alkalmazások fejlesztési technológiái Áttekintés

Simon Balázs Dr. Goldschmidt Balázs Dr. Kondorosi Károly. BME, Irányítástechnika és Informatika Tanszék

A J2EE fejlesztési si platform (application. model) 1.4 platform. Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

SOA modell: Ez az interfész definiálja az elérhető adatokat, és megadja, hogy hogyan lehet azokhoz hozzáférni.

Bevezetés az SAP világába. 5. Kommunikációs és integrációs technológiák

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

Üzleti szabálykezelés

JAVA webes alkalmazások

Feltörekvő technológiák: seam, drools, richfaces és társai a JBossban

A Java EE 5 plattform

S04-2 Elosztott alkalmazások készítése

A szervezeti architektúra nézetei, nézőpontjai és tervezési módszerei. Szolgáltatás orientált architektúrák információs rendszerekben

Oracle integrációs platform nem csak Oracle Alkalmazásokhoz

SOA ALAPÚ INTEGRÁCIÓS LEHETŐSÉGEK AZ E-KÖZIGAZGATÁSBAN

Webszolgáltatás alapokon BPEL

Integrációs mellékhatások és gyógymódok a felhőben. Géczy Viktor Üzletfejlesztési igazgató

Automatikus infrastruktúra menedzsment és alkalmazástelepítés

Web Services. (webszolgáltatások): egy osztott alkalmazásfejlesztési plattform

Oracle Enterprise Manager: Az első teljesértékű felhő üzemeltetési megoldás

Viczián István IP Systems JUM XIX szeptember 18.

Enterprise extended Output Management. exom - Greendoc Systems Kft. 1

Szolgáltatásorientált rendszerintegráció. SOA-alapú rendszerintegráció. Web-szolgáltatások: SOAP, WSDL

pilot példa SOA alkalmazásra április 29.

Az alkalmazás minőségbiztosítás folyamata Fókuszban a teszt-automatizálás

IBM Business Process Manager változat 8 alváltozat 5. Az IBM Business Process Manager áttekintése

Fejlesztés, működtetés, felügyelet Hatékony infrastruktúra IBM szoftverekkel

Webszolgáltatások kommunikációs overhead-jének becslése

Párhuzamos és Grid rendszerek

Oracle Containers for Java - j2ee alkalmazás szerver funkciók. Molnár Balázs Oracle Hungary

Petőfi Irodalmi Múzeum. megújuló rendszere technológiaváltás

Folyamatmodellezés (BPMN) és alkalmazásai

OKTATÁSI CSOMAG (SOA)

Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

A cloud szolgáltatási modell a közigazgatásban

ALKALMAZÁS KERETRENDSZER

Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék. Folyamatmodellezés

Webszolgáltatások (WS)

Nagy bonyolultságú rendszerek fejlesztőeszközei

Komponens modellek. 3. Előadás (első fele)

Szolgáltatás technológiák (WS, WS-*) Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

SZOLGÁLTATÁS ORIENTÁLT ARCHITEKTÚRÁK (SOA)

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

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

ETL keretrendszer tervezése és implementálása. Gollnhofer Gábor Meta4Consulting Europe Kft.

Felhő alkalmazások sikerének biztosítása. Petrohán Zsolt

DCOM Áttekintés. Miskolci Egyetem Általános Informatikai Tanszék. Ficsor Lajos DCOM /1

Kommunikációs middleware megoldások

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

Folyamatok rugalmas irányítása. FourCorm Kft.

Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom

Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K. 4. A meghirdetés ideje (mintatanterv szerint vagy keresztfélében):

Szoftver Tervezési Dokumentáció. Nguyen Thai Binh

Folyamattervezéstıl a megvalósításig

webalkalmazások fejlesztése elosztott alapon

BMEVIHIM134 Hálózati architektúrák NGN menedzsment vonatkozások: II. Üzemeltetés-támogatás és üzemeltetési folyamatok

Mobil szolgáltatások és alkalmazások fejlesztése

Osztott rendszerek (Distributed. systems) Bevezetés. Tartalom. Ficsor Lajos. Miskolci Egyetem Általános Informatikai Tanszék

Nyilvántartási Rendszer

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

SOA rendszerek felügyelete és vizualizációja

(Web)Szolgáltatások (WS, WS-*)

IT Szolgáltatás Menedzsment az oktatási szektorban - 90 nap alatt költséghatékonyan

Hargitai Zsolt Novell Mo.

Adatbázis rendszerek 7. előadás State of the art

Webes alkalmazások fejlesztése 12. fejezet. Szolgáltatás alapú kommunikáció (WCF) Giachetta Roberto. Eötvös Loránd Tudományegyetem Informatikai Kar

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

Oracle Middleware megoldások helye üzleti esettanulmányokon keresztül bemutatva, különböző iparágakban

UNIX: folyamatok kommunikációja

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Osztott rendszerek (Distributed

Osztott Objektumarchitektúrák

Oracle GoldenGate Studio Nagyon rövid bemutató. Quick Talk. Gollnhofer Gábor

Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon

stratégiai kutatási terve


Alkalmazásokban. Dezsényi Csaba Ovitas Magyarország kft.

A számítástechnika gyakorlata WIN 2000 I. Szerver, ügyfél Protokoll NT domain, Peer to Peer Internet o WWW oftp opop3, SMTP. Webmail (levelező)

Szolgáltatási szint és performancia menedzsment a PerformanceVisor alkalmazással. HOUG konferencia, 2007 április 19.

Hogyan lehet megakadályozni az üzleti modellezés és az IT implementáció szétválását? Oracle BPM Suite

S01-7 Komponens alapú szoftverfejlesztés 1

Szoftver újrafelhasználás

Komponens alapú fejlesztés

Flex: csak rugalmasan!

Data Integrátorok a gyakorlatban Oracle DI vs. Pentaho DI Fekszi Csaba Ügyvezető Vinnai Péter Adattárház fejlesztő február 20.

Everything Over Ethernet

Web service fenyegetések e- közigazgatási. IT biztonsági tanácsadó

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

Izsó Krisztián Péti Zoltán. Cisco Identity Services Engine

Szemantikus webszolgáltatások használatát támogató middleware. Kovács László, Micsik András, Tóth Zoltán DSD MTA SZTAKI. Elosztott Rendszerek Osztály

Az OpenScape Business rendszerek egységes architektúrára épülnek: Rugalmas, skálázható és megbízható

SOAP komponensek Delphiben

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

Átírás:

Nagyvállalati SOA infrastruktúra (ESB, szolgáltatástárak) Szolgáltatásintegráció előadás Huszerl Gábor, Gönczy László (BME MIT) Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Kérdések Szolgáltatás-orientáltság platform függetlenül? A WS is csak egy platform A SOA alatt lehet más is A szolgáltatás örök, a platform változik Hogyan érik el a szolgáltatások egymást? kell egy platform (topológia is!) Java API, WS világ spagetti architektúra, Bábel kommunikációs infrastruktúra (üzenetsín)

Szolgáltatás-orientált rendszerek Alapfogalmak Szolgáltatás, alkalmazás, rendszer Interfész kiajánlott felület Referencia elvárt/használt felület Megvalósítás kibontás vagy technológiához kötés Üzleti objektumok üzenet/hívás adatstruktúrák

Service Component Architecture Open SOA Collaboration tervezési modellje SCA 1.0 2007 márciusában Formális szabványosítás: OASIS Jobbára Java környéki cégek BEA, Fiorano, IBM, Iona, Oracle, Red Hat, SAP, Siemens, Sun, Sybase, Tibco, Microsoft hasonló koncepciója: Windows Communication Foundation Inkább komm. platform, mint tervezési modell Portolhatóságot tűz ki

SCA referencia modell Kompozit: komplex, szolgáltatást nyújt, igénybe vesz Szolgáltatás: publikus (absztrakt) interfész (+ huzalozás!) Referencia: elvárt szolgáltatások (absztrakt) interfésze Tulajdonság: paraméterek, konfiguráció Komponens: a szolgáltatáslogika összetevője

Kompozit Komplex, szolgáltatást nyújt, igénybe vesz Milyen elemekből? (top-down jelleg) Melyik szolgáltatást ki nyújtja? Ki kivel kommunikál? Lehet telepítési egység (deployment package) Lehet azonos környezetben futási egység A belső kommunikáció nem távoli jellegű Lehet láthatósági egység (visibility scope) include -olt elemek mindig látnak és láthatóak

Szolgáltatás, referencia Nyújtott szolgáltatás publikus (abszt.) interfésze Elvárt szolgáltatások (absztrakt) interfésze Leírás nyelve tetszőleges Ha távoli kommunikációt feltételez, akkor WSDL-be fordíthatónak kell lennie Hosszú távú kapcsolódást külön jelölni Session, conversation Implementáció: WSDL, Java interfész/osztály, JMS binding,...

Komponens A szolgáltatáslogika összetevője Alacsonyabb szintű kompozit (rekurzivitás) Java osztály, BPEL folyamat Implementáció: BPEL, JSP, POJO, egyéb nyelvű program, selector, human task, business rule, business state machine,...

SCA kötése hordozóprotokollhoz SCA platformfüggetlen, megvalósítás nem Üzleti logika leválasztása az elérés megvalósításáról (de az is kell valahol!) Szolgáltatások/referenciák kötése (binding) Hogyan hívható, hogyan akar hívni SCA sokféle kötést ismer (WS, EJB, JMS, JCA,...) SCA alapú eszköz ezt bővítheti Vezetékezés megvalósítása: SCA motorra bízva Mit köt össze a vezeték, mit ismer a motor Ha interoperabilitás kell WS

Adatáramlás szolgáltatások között Referenciák és szolgáltatások összehuzalozása Szép, de önmagában nem elegendő Adatstruktúra egyezést deklarál Eltérő platformú szolgáltatások között probléma Business Object on the Wire Java osztály Service Data Object

Mire jó az SCA/SDO? Referenciamodell Eszközök építhetőek rá Modellező eszközök Fejlesztő eszközök (Java5 annotációk) Végrehajtó motorok Szolgáltatás-orientált fejlesztés Meglévő alkalmazások beillesztése Bármi SCA komponensbe csomagolható

Kérdések Szolgáltatás-orientáltság platform függetlenül? A WS is csak egy platform A SOA alatt lehet más is A szolgáltatás örök, a platform változik Hogyan érik el a szolgáltatások egymást? kell egy platform (topológia is!) Java API, WS világ spagetti architektúra, Bábel kommunikációs infrastruktúra (üzenetsín)

A SOA infrastruktúra problémája Nagyvállalati informatikai rendszerek sok funkció, sok alrendszer, szervezeti hierarchia heterogén technológiák, evolúció (üzlet, technológia) több száz/ezer szolgáltatás ezek kommunikációja szolgáltatássínek ezek kézben tartása szolgáltatástárak

Platformfüggetlenség Szabványosítás (nemzetközi, állami, iparági/ipari) Cégek közötti megállapodás (piaci részesedés) Nem kötelező érvényű Közös érdek, közös álláspontot tükröz Korlátozza a vevő röghöz kötés -ét Korlátozza a gyártó innovációs szabadságát Többféle szinten lehetséges Pl. portolhatóság, interoperabilitás

Szolgáltatás-orientált rendszerek & Java Java kiegészítése szolg. alapú integrációhoz? JSR-208 (2005) Java Business Integration 1.0 JSR-312 (?) Java Business Integration 2.0 WS + Java alapú EAI/B2B jellegű integráció (ESB) Java szabvány csak egy API Nem vetélytársa az SCA/SDO-nak Implementációk Apache ServiceMix, Fuse ESB, JBoss ESB, OpenESB, Sun Glassfish, TIBCO ActiveMatrix, Oracle Fusion,...

SOAP alapú kommunikáció Küldő Címzett Alkalmazásszintű hívás/üzenet

SOAP alapú kommunikáció Küldő Címzett Alk. hívás/üzenet Alk. hívás/üzenet Csonk (marshalling/demarshalling) hívás/üzenet megy a törzsbe csonk kitölti a fejrészt Csonk Marshalling SOAP üzenet (borítékolt XML) kódolt üzenetek (SOAP Section 5) (Programnyelvi típusok kódolása SOAP szabvány szerint. Ma ritka.) betű szerinti üzenetek (literal) (Kódolás a WSDL-beli XSD szerint, akár komplex típusok. Általános.)

SOAP alapú kommunikáció Küldő Címzett Alk. hívás/üzenet Csonk (marshalling/demarshalling) hívás/üzenet megy a törzsbe csonk kitölti a fejrészt Alk. hívás/üzenet Csonk Marshalling SOAP üzenet (borítékolt XML) XML-RPC (SOAP Section 7) SOAP használata RPC-re (metódusnév, metódusnévresponse, Fault; kódolt üzenetek) Document (lehet kódolt vagy betű szerinti)

SOAP alapú kommunikáció Küldő Címzett Alk. hívás/üzenet Alk. hívás/üzenet Csonk SOAP (borítékolt XML) Csatlakozó (binding) Csonk SOAP (borítékolt XML) Csatlakozó SOAP over HTTP(S)/JMS/MQ/SMTP/TCP/fax/postagalamb/... (karakteres tartalom átvitele)

SOAP alapú kommunikáció Küldő Címzett Alk. hívás/üzenet Alk. hívás/üzenet Csonk Átjáró Csonk SOAP (borítékolt XML) SOAP SOAP SOAP (újraborítékolt XML) Csatlakozó Csatlakozó Csatlakozó Csatlakozó SOAP over? SOAP over?

SOAP alapú kommunikáció Küldő Címzett Alk. hívás/üzenet Alk. hívás/üzenet Csonk Átjáró Csonk SOAP (borítékolt XML) SOAP SOAP SOAP (újraborítékolt XML) Csatlakozó Csatlakozó Csatlakozó Csatlakozó SOAP over? SOAP over? Ezért nem bízhatunk mindent a hordozó protokollra WS-* (WS-Addressing, WS-RM, WS-Security,...)

Kommunikációs topológiák Hagyományos WS: bedrótozott pont-pont topológia minden változáskor kód módosítás módosítás hatása beláthatatlan kereskedelmi termékekben lehetetlen teljes gráf topológiához tart rugalmatlan, üzemeltethetetlen minden küldő minden címzetthez külön csonkot tart (esetleg több átviteli protokollhoz többet) Sín topológia jobban kézben tartható

JBI környezet

ESB Enterprise Service Bus Nagyvállalati szolgáltatássín Kommunikációs infrastruktúra nem pont-pont kapcsolat aszinkron kommunikáció (üzenet alapú) (laza csatolásért) eseményvezérelt működés üzenetek intelligens szűrése, átalakítása üzenetek intelligens irányítása (útvonalválasztás) protokoll átjáró (HTTP, MQ, SMTP,...)

ESB definíciók 1. Gartner Group: EAI rendszerek olcsó, egyszerű alternatívája IDC: a jövő nyílt, szabványos összekapcsolási gerince ZapThink: szolgáltatás-orientált interfésszel rendelkező üzenetsín

ESB definíciók 2. Kisebb gyártók: WS, JMS alapú middleware termékek Nagyobb gyártók: MQ, workflow alapú EAI termékek/rendszerek Elmélet: Nagyvállalati információs rendszerek SOA alapú összekapcsolási infrastruktúrája

ESB elődei Nagyvállalati üzenetkezelés (enterprise messaging) nagy sebességű, aszinkron, bárki-bárkivel nagy megbízhatóság, jó skálázhatóság akár saját formátum nem szolgáltatás-orientált Üzenetközvetítők (message brokers) laza integráció, P/S Web Services technológiák nyílt szabványok, platformfüggetlenség

Első generációs ESB-k Csak nyílt szabványokra építenek Olcsó megvalósítás Senki nem kompatibilis velük fokozatos átállás lehetséges csak Kiforratlan szabványok WS, WS-*, JCA,... Teljesítmény és funkcionális korlátok

ESB Elvárások 1. Kommunikációs middleware szinkron/aszinkron, request-reply, one-way, call-back,... P/S funkciók (üzenetek, témák, előfizetés, elosztás) QoS (biztonság, megbízhatóság, teljesítmény, tranzakciók) szabványos API-k és protokollok Hívások/válaszok feldolgozása menet közben fordítás, átalakítás, szűrés, kiegészítés (XSLT) naplózás, (üzleti) monitorozás Szabványos kapcsolódási lehetőség

ESB Elvárások 2. Lazán csatolt komponensek és együttműködésük menedzselése Érvényesség és jogosultság ellenőrzés üzenet formátum (tartalom) érvényessége legalább XML validálás küldő identitása és jogosultsága, üzenetváltások címzett nem látja a küldőt jogosultságok központi karbantartása

Érdekes ESB megoldások 1. P2P alapú ESB Minden gépen egy-egy P2P szerver teljesítmény, skálázhatóság P2P szerverek hálózata belül RPC+MQ megoldások, nem érdekes super peer központi funkciókkal (menedzsment, biztonság) WS interfész a helyi üzleti komponensek felé

Érdekes ESB megoldások 2. Útiterv alapú irányítás Tartalom alapú helyett Feladó minden érintendő komponenst előre megad (mint a poggyásznál a repülőn, azután letépkedés ) ESB komponens transzformálhat, kifelé akciózhat, de belül továbbad Nem kell központi komponens ( mediáció )

SOA infrastruktúra (tárak) Szolgáltatásintegráció előadás Huszerl Gábor, Gönczy László (BME MIT) Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Kérdések Mi legyen, ha sok szolgáltatás van? Hogyan érik el a szolgáltatások egymást? spagetti architektúra, Bábel kommunikációs infrastruktúra (üzenetsín) Milyen szolgáltatásaink vannak már? szolgáltatások életciklusa, verziók szolgáltatás tárak

A SOA infrastruktúra problémája Nagyvállalati informatikai rendszerek sok funkció, sok alrendszer, szervezeti hierarchia heterogén technológiák, evolúció (üzlet, technológia) több száz szolgáltatás ezek kommunikációja szolgáltatássínek ezek kézben tartása szolgáltatástárak

Szolgáltatástárak Service registry (nyilvántartás, nem repository!) Klasszikus WS technológia Csak szolgáltatások közvetítésére Tárak használata megvalósításkor Elkészít bejegyez Megkeres letölt csonkot épít használ UDDI, WSIL szabványok SOA elképzelés Teljes életciklus kezelés (ötlettől felszámolásig) Tervezéskor, megvalósításkor, futás közben

UDDI Universal Description, Discovery and Integration Szolgáltatások szabványos regisztrációja és felderítése Megosztott, kereshető web alapú tár (telefonkönyv) telefonkönyv színek (fehér, sárga, zöld) Eredetileg tár az ebxml-hez (2000-2002 környékén) Publikus, privát, osztott/félprivát tárak

Universal Business Registry UDDI Business Registry (UBR, UDDI alapú szolgáltatástár) Felépítése: Business Entity (cég, cég rész) Business Service (szolgáltatás) Binding Template t_model (adott című interfész megvalósítás milyen szabványoknak/specifikációknak felel meg) Binding Template t_model Business Service Binding Template t_model Business Entity Business Service Binding Template t_model

UDDI hátrányai Bejegyzések 2/3-a használhatatlan Karbantartás, megszűnő szolgáltatások törlése Publikus tárban kinek a felelőssége? Publikus tárak üzleti modellje? Szó sincs SLA-ról, QoS-ről A szolgáltatások szemantikájáról sincs gyártóspecifikus megoldások open source http://www.tutorialspoint.com/uddi/uddi_implementations.htm

WSIL WS Inspection Language WS Szemlélőnyelv (szemlélő/inspektor, szemrevételező) IBM, MS (2001 vége) UDDI tárak helyett Bárki bárkivel technikailag lehetséges Nem műszaki okok miatt mégsem Bárki bárki ismerőssel off-line kapcsolat fontos Nem telefonkönyv kell, hanem névjegyek Elérhetőségi adatok decentralizált publikációja mindenki a saját adatait a saját webszerverén Fontos infók: Szolgáltatások/interfészleírások elérhetősége Elérhetőségek elérhetősége

WSIL szokások Fix WSIL leírás címek Minden WS-t nyújtó webszervernek illene Humán és robot keresést is egyszerűsíti WSIL leírások egymásra hivatkozása Hierarchikus elrendezés, szervezeti hierarchia Szolgáltatások csoportosítása funkció vagy szolgáltató szerint Karbantartás felelőssége tiszta

WSIL & UDDI WSIL szerint a szolgáltatás leírás helye lehet WSDL fájl egy webszerveren Adott kulcsú bejegyzés egy UDDI tárban WSIL hivatkozhat WSIL fájlra UDDI Business Entity -re (egy cég UDDI-ban) UDDI-ban Business Entity adatai között Központi WSIL leírása

SOA és szolgáltatástárak SOA alapú megoldások egy cégen belül is sok szolgáltatás A káosz uralása governance (irányítás) útmutatások, ellenőrzés és kikényszerítés fejlesztés, üzemeltetés, rendtartások, metaadatok, eljárások, szerepek, erőforrások, technológiák, bevált megoldások, portfólió- és életciklus-kezelés, konzisztencia, teljesítmény minőségbiztosítás (bürokrácia és áttekinthetőség) ez már inkább repository A káosz uralása menedzsment (felügyelet) folyamatok, életciklus, gazdálkodás, monitorozás

Szolgáltatástárak tartalma Meglévő szolgáltatások listája Mi az, ami már van? Ki használja? (verziók, függőségek) Elérhetőségek (felderítés), szemantika leírás (doksik) Metaadatok (+szabvány/törvény konformancia) Készülő szolgáltatások listája Nem csak azt nem kell legyártani, ami már van, hanem azt sem, ami már készül Előfizetett szolgáltatások listája Jó külső szolgáltatások listája Hatékony újrahasznosítás!!!

Szolgáltatások metaadatai Szolgáltatás választás akár futási időben Metaadatok alapján funkcionalitás, tervező, gondozó, jogosultságok, rendtartások, konfigurációs beállítások, üzleti paraméterek (business rules) teljesítmény, rendelkezésre állás (mikor), SLA verziók, életciklus fázis, várható indítás/váltás/leállítás ideje tanúsítványok, vonatkozó szabványok/törvények kapcsolódó protokollok, formátumok, adatstruktúrák, modellek, kapcsolódó szolgáltatások aktuális terhelés, megbízhatóság, elérhetőség (fut-e, elérhető-e) költségek, biztonsági besorolás statisztikák, jelentések