ebXML technikai architektúra specifikáció Forrás: ebXML Technical Architecture Specification v1.0.4 ebXML Technical Architecture Project Team február 16. Közreműködők: EDI France, a DataChanel, az XML Global Technologies, US Army, Sun Microsystems, IBM, OMG, stb. munkatársai. 1

ebXML TA 3 Bevezetés 3.1 A dokumentum tartalmának összefoglalója RFC 2119 Tartalomjegyzék 3.2 Hallgatóság és hatókör Ez a dokumentum leírja az ebXML alapját képező architektúrát. Térképként használandó ahhoz, hogy megismerjük az ebXML-t, az ebXML-lel megoldható feladatokat, és a központi (core) ebXML funkcionalitást és architektúrát. 3.3 Kapcsolódó dokumentumok Követelmények Üzleti folyamat és információs meta modell Központi elemek Regiszter és tárház Kereskedelmi partner információk Üzenetváltó szolgáltatások Ezek a specifikációk letölthetők a helyről. 2

ebXML TA 3.4 Normatív hivatkozások A következő szabványok rendelkezéseket tartalmaznak, melyek jelen specifikáció kikötéseit is alkotják a szövegben való hivatkozás által. 4 Tervezési szempontok 4.1 Feladat leírás és célok az ebXML számára EDI, elektronikus adatcsere. Az EDI megvalósítások tekintélyes mennyiségű tapasztalatot kódoltak a Business Processek-be (üzleti folyamatok). eXtensible Markup Language (XML, kiterjesztett jelölő nyelv). Az ebXML specifikációk olyan keretet biztosítanak, amelyben az EDI üzleti folyamatokba történt hatalmas befektetése megőrizhető egy olyan architektúrában, ami kiaknázza az XML új technikai lehetőségeit. Az ebXML alap célkitűzéseivel kapcsolatos információkat az ebXML Requirement Specification (követelmény specifikáció) tartalmazza. 3

ebXML TA 4.2 Caveats és feltételezések Ez a specifikáció az ebXML magas szintű áttekintésére készült, és mint ilyen nem biztosítja azt a részletességet, amit az ebXML alkalmazások, komponensek és a kapcsolódó szolgáltatások építése igényel. 4.3 Az ebXML specifikációk kivitelezési konvenciói Az „Upper Camel Case” (UCC) és a „Lower Camel Case” (LCC) nagybetűsítési stílust fogjuk (SHALL) használni. Az elemek nevei UCC konvenció szerintiek lesznek (például: ). Az attribútum nevek LCC konvenció szerintiek lesznek (például: ). A Class (osztály), Interface (interfész), Association (társítás), Package (csomag), State (állapot), Use Case (), Actor (szereplő) nevek az UCC stílust fogják használni (például: ClassificationNode, Versionable, Active, InsertOrder, Buyer). 4

ebXML TA Az Attribute (tulajdonság), Operation (művelet), Role (szerep), Stereotype (), Instance (példány), Event (esemény), Action (akció) nevek az LCC stílust fogják használni (például: name, notifySender, resident, orderArrived). A betűszavak kerülendők. Az aláhúzás (_), a pont (.) és a kötőjel (-) jeleket tilos használni. 5 ebXML rendszer áttekintés Az 1. ábra magasszintű alkalmazási forgatókönyvet mutat két kereskedelmi partner esetén, az első konfigurál és elkötelezi magát egy egyszerű üzleti tranzakcióban és cserében. Ez a modell egy példa, amely bemutatja a szükséges folyamatot és lépéseket az ebXML alkalmazás konfigurálásához és bevetéséhez, és a kapcsolódó architektúra komponenseket is. 5

ebXML TA Fogalmak és az azokat megalapozó architektúrák: 1. üzleti folyamat (BP, Business Process) és információs modellje, 2. az üzleti folyamat és az információs meta modellek (IMM, Information Meta Models) nyilvántartási és tárolási mechanizmusa. 3. A résztvevők következő információinak felderítése : Az általuk támogatott üzleti folyamatok. Az üzleti folyamatok támogatásához felajánlott üzleti szolgáltatási interfészek (BSI, Business Service Interfaces). Az üzleti üzenetek (BM, Business Messages), melyeket a megfelelő üzleti szolgáltatási interfészek között váltanak. A támogatott szállítási, biztonsági és titkosítási protokollok technikai konfigurációi. 4. Az előzőleg említett információk nyilvántartási mechanizmusa annak érdekében, hogy azok felfedezhetők és lehívhatók legyenek. 5. Mechanizmus a kölcsönösen egyeztetett üzleti megállapodás –ami a részvevők 3. pontban említett információiból vezethető le- végrehajtásának leírására. (Collaboration Protocol Agreement, CPA, Együttműködési Protokoll Egyezmény) 6

ebXML TA 6. Szabványosított üzleti üzenet szolgáltatási (Meesaging Service) keret, ami lehetővé teszi az együttműködő, biztonságos és megbízható üzenetváltást a kereskedő partnerek között. 7. Az üzenet szolgáltatások konfigurálási mechanizmusa, hogy összekapcsolódjanak a megegyezett üzleti folyamat alapján, az üzleti megállapodásban meghatározott korlátoknak megfelelően. 7

ebXML TA 8 1.ábra Két társaság együttműködésének magasszintű áttekintése, akik az ebXML használatával eBusiness-t folytatnak

ebXML TA 6 Javasolt ebXML modellezési módszertan Az üzleti folyamat és információ modellezés nem kötelező. Mégis, ha az implementálók és a felhasználók az üzleti folyamatok és információk modellezését választják, akkor használják az UN/CEFACT Modeling Methology-t (UMM, modellezési módszertan), ami felhasználja az UML-t. 6.1 Áttekintés Miközben az üzleti gyakorlat szervezetenként nagyon változatos, a legtöbb tevékenység üzleti folyamatokra bontható, melyek általánosak az egyes üzlettípusokra nézve. Az UN/CEFACT modellezési módszertan (UMM) a következő két nézetet használja az eBusiness tranzakciók jellegzetességeinek leírására. Ez a modell az Open-edi Reference Model-len alapul, ISO/IEC Az UMM az üzleti műveleti nézetre (BOV, Business Operational View) és az azt támogató, fent leírt funkcionális szolgáltató nézetre (FSV, Functional Sevice View) bomlik. 9

ebXML TA 2.ábra Az ebXML javasolt modellezési metódusa 10

ebXML TA A BOV megcélozza: Az üzleti adatok szematikáját a tranzakciókban és a kapcsolódó adatcserékben Az üzleti tranzakciók architektúráját Az FSV a támogató szolgáltatásokat célozza meg : Funkcionális képességek Üzleti szolgáltatás interfészek Protokollok és üzenetváltó szolgáltatások 6.2 Az ebXML üzleti műveleti nézete Az ebben a szakaszban leírt modellezési technikák nem kötelező előírások az ebXML alapú üzleti tranzakciókban való részvételhez. 11

ebXML TA 3.ábra Az üzleti műveleti nézet részletes bemutatása 12

ebXML TA Az első fázis meghatározza a követelmény alkotókat (artifact?). A második fázisban (analízis) létrehozzuk a tevékenység és sorrend diagramokat (amint azt az UMM specifikációban meghatározták), amelyek leírják az üzleti folyamatokat. Az ebXML-ben az együttműködést az üzleti információs objektumoknak (Business Information Objects) az összes osztály modellben való alkalmazásával érjük el. 6.3 Az ebXML funkcionális szolgáltatás nézete Amint az a 4.ábrán látható az ebXML regiszter szolgáltatás (Registry Service) az üzleti folyamat és információs modell, ezen modellek XML-alapú ábrázolásához, a központi elemek, és az együttműködési protokoll profilok (CPP) tároló eszközeként szolgál. 13

ebXML TA 14 4.ábra

ebXML TA 7 Az ebXML funkcionális fázisai 7.1 Implementációs fázis Az implementációs fázis kimondottan azokkal az eljárásokkal foglalkozik, amelyekkel az ebXML infrastruktúra alkalmazása létrehozható. Az 5.ábra az ebXML regiszter szolgáltatás és a kereskedő partner közötti alap együttműködést mutatja be. 15

ebXML TA 16 5.ábra Funkcionális szolgáltatási nézet: az implementációs fázis

ebXML TA 7.2 Felderítési és lehívási fázis A felderítési és lehívási fázis az ebXML-lel kapcsolatos források felderítésének minden oldalát lefedi. 17

ebXML TA 6.ábra Funkcionális szolgáltatási nézet: Felderítési és lehívási fázis 18

ebXML TA 7.3 Futásidejű fázis A futásidejű fázis lefedi az ebXML forgatókönyv végrehajtását a hozzátartozó aktuális ebXML tranzakciókkal ábra Funkcionális szolgáltatási nézet: Futásidejű fázis

ebXML TA 8 Az ebXML infrastruktúra 8.1 Kereskedő partner információ (CPP és CPA-k) Bevezetés Az eBusiness végzése folyamatának elősegítésére a lehetséges kereskedő partnereknek szükségük van egy olyan mechanizmusra, amely lehetővé teszi az általuk támogatott üzleti folyamatok információit közzétenni, az üzleti információk cseréjére vonatkozó képességeik sajátos technológiai implementációjának részleteivel együtt. Ezt a CPP használatával teljesítik. Egy bizonyos üzleti szerződés, amit CPA-nak hívunk, kettő vagy több CPP metszetéből származik CPP formális funkcionalitás A CPP leírja azokat a sajátos képességeket, melyeket a kereskedő partner támogat, és a szolgáltatási interfész követelményeket is, amelyeknek meg kell felelni, hogy azzal a kereskedő partnerrel üzleti dokumentumokat lehessen cserélni. 20

ebXML TA A CPA formális funkcionalitása Az együttműködési protokoll megállapodás (CPA, Collaboration Protocol Agreement) olyan dokumentum, ami két CPP metszetét jelent, és amiben mindkét kereskedő partner, akik az ebXML használatával kívánnak eBusinesst folytatni, kölcsönösen megegyezett ábra A CPA háromszintű nézete

ebXML TA Az üzleti együttműködés az az elsőszámú támogatás, amit az ebXML kereskedő partnerek igényelhetnek ábra A CPA-k hatásköre

ebXML TA CPP interfészek Interfész az üzleti eljárásokhoz A CPP-nek képesnek kell lennie a CPP példányával rendelkező kereskedő partnerek által támogatott, egy vagy több üzleti folyamatra hivatkozni CPA interfészek A CPA-knak van interfésze a CPP-khez, ebben a CPA a kölcsönös tárgyalási folyamat során a kereskedő partnerek képességeit (CPP) szűkíti arra (CPA), amit a kereskedő partnerek meg akarnak csinálni A CCP-k és CPA-k nem előírásszerű implementációs részletei A CPA-t a felderítési és lehívási fázis után tárgyalják meg, és lényegében az üzenet szolgáltatásokkal és üzleti folyamatokkal kapcsolatos információk pillanatfelvétele, amiben kettő vagy több kereskedő partner megegyezik, hogy az üzleti információk cseréjére használják. 23

ebXML TA 8.2 Üzleti folyamat és információ modellezés Bevezetés Az ebXML üzleti folyamat és információs meta modell olyan mechanizmus, ami lehetővé teszi a kereskedő partnereknek a sajátos üzleti forgatókönyvek részleteinek megragadását egy konzisztens modellezési metódussal. Az ebXML üzleti folyamat és információs meta modell támogatja a követelmény, az analízis és a tervezési szempontokat, melyek egy szemantika halmazt (szótárt) adnak mindenegyes szempontra, és azon művek specifikációjának alapját alkotják, melyek szükségesek az üzleti folyamat és információ integrálásához és együttműködőképességéhez. A specifikációs séma két különálló megjelenési formában áll rendelkezésünkre, az UML profil és a DTD alakban. Az ebXML üzleti folyamat és információs metamodell és az ebXML specifikációs séma közötti kapcsolat a következőképpen szemléltethető: 24

ebXML TA A specifikációs séma támogatja az üzleti tranzakciók specifikálását és az üzleti tranzakciók összeállítását üzleti együttműködéssé. Mindenegyes üzleti tranzakció a sok rendelkezésre álló szabványos minta egyikének felhasználásával implementálható ábra ebXML metamodell – szemantikus részhalmaz

ebXML TA Az üzleti folyamat teljes specifikációja az üzleti folyamat és információs metamodellből, melyet a specifikációs sémára specifikáltak, és a kívánt minta(k) azonosításából áll. Nincs semmiféle hivatalos követelmény egy új üzleti folyamat összeállításánál valamilyen modellező nyelv használatára, mégis ha modellező nyelvet használunk az üzleti folyamat kifejlesztésére, akkor az az UML (Unified Modeling Language) legyen. A konzisztens üzleti folyamatok és információs modellek létrehozásának további elősegítésére az ebXML az üzleti folyamatok általános halmazát definiálja a központi könyvtárral párhuzamosan. 26

ebXML TA 11.ábra Az ebXML metamodell 27

ebXML TA Formális funkcionalitás Az üzleti folyamat dokumentum példányainak ábrázolása olyan formában lesz, ami lehetővé teszi az információk olvasását mind az ember, mind az alkalmazások számára. Ez szükséges az üzleti tranzakciók teljes automatizálásához való átmenet elősegítésére Interfészek Kapcsolat a CPP-hez és a CPA-hoz Kapcsolat a központi elemekhez Kapcsolat az ebXML üzenetváltóhoz Kapcsolat a regiszter rendszerhez 28

ebXML TA 12.ábra Az ebXML üzleti folyamat és információ medellező réteg 29

ebXML TA 8.3 Központi elemek és központi könyvtár funkcionalitás Bevezetés A központi elem egy valóságos üzleti elv információit és az elv közötti kapcsolatokat ragadja meg; egy adott ebXML forgatókönyvben további üzleti információs objektumok, és egy kontextuális leírás, ami leírja a központi vagy összevont információ entitásokat használható Formális funkcionalitás Interfészek A központi elem legyen hivatkozható közvetetten vagy közvetlenül egy üzleti dokumentum példányból Nem-előírásos implementációs részletek A központi elem tartalmazhat attribútumo(ka)t, vagy része lehet egy másik központi elemnek, tehát meghatározza használatának pontos kontexusát vagy a kontexusok kombinációját. 30

ebXML TA 13.ábra Az üzleti kontexus meghatározása az aggregált kontexus, az aggregált információ egyed és a központi elem kifejezésekkel 31

ebXML TA 8.4 Regiszter funkcionalitás Bevezetés Az ebXML regiszter biztosít egy sor szolgáltatást, amely lehetővé teszi a kereskedő partnerek közötti információ megosztást. A regiszter egy olyan komponens, ami a regisztrált tétel metaadatához interfészt tart fenn. Az ebXML regiszterhez való hozzáférést interfészeken (API-k) keresztül biztosított, melyeket a regiszter szolgáltatások tesznek közzé. 32

ebXML TA 14.ábra Átfogó regiszter architektúra 33

ebXML TA Formális funkcionalitás A regiszter biztosítson tárolóhelyet olyan tételek számára, melyek multibyte karakter készleteket használó szintaxisban fejeznek ki. A regiszter interfész alkalmazás-regiszter hozzáférési mechanizmusként szolgál. Az ember-regiszter együttműködést a regiszter interfész feletti rétegként kell megépíteni (pl. egy Web böngésző) és nem különálló interfészként. A regiszter interfészt úgy kell megtervezni, hogy az független legyen a támogató hálózati protokoll készlettől (pl. HTTP/SMTP a TCP/IP felett). Megfelelő biztonsági protokollok vethetők be, hogy hitelesítést és védelmet ajánljunk a tárház számára, amikor azt a regiszterrel érjük el. Egyedi azonosítókat (Unique Identifiers, UIDs) kell hozzárendelni minden tételhez az ebXML regiszter rendszeren belül. Az üzleti folyamat és információ meta modell szemantikus megismerése elősegítéséért a regiszter szolgáltatás mechanizmust biztosít a regiszter tételek ember által olvasható leírásának befoglalására. 34

ebXML TA Interfészek ebXML üzenetváltás A regiszter elérési mechanizmusokban használt lekérdezési szintaxis független a backend rendszer fizikai megvalósításától. Üzleti folyamat Tetszőleges meta adattal leírt tétel Nem-előírásos implementációs részletek A létező ISO 11179/3 munka a regiszter implementációkról, modellként használható az ebXML regiszter megvalósításokhoz. Az ebXML regiszter szolgáltatás üzleti folyamat és információ meta modellje lehet a létező OASIS Registry/Repository technikai specifikációjának kiterjesztése. 35

ebXML TA 8.5 Üzenetváltó szolgáltatási funkcionalitás Bevezetés Az ebXML üzenetváltó szolgáltatási mechanizmus az ebXML kereskedő partnerek közötti üzleti üzenetek cseréjének szabványos módját biztosítja. Az ebXML üzenetváltó szolgáltatás megbízható eszközt biztosít az üzleti üzenetek cseréjére anélkül, hogy szabadalmaztatott technológiákra és megoldásokra építene. Az ebXML üzenetváltó szolgáltatás fogalmilag három részre osztott: (1) absztrakt szolgáltatási interfész, (2) az üzenetváltó szolgáltatási réteg, és (3) leképezés az alap szállítási szolgáltatás(ok)ra. 36

ebXML TA 15.ábra Az ebXML üzenetváltó szolgáltatás 37 A 16. ábra az ebXML üzenetváltó szolgáltatás architektúráján belül lévő funkcionális modulok logikai elrendezését ábrázolja.

ebXML TA ábra Az üzenetváltó szolgáltatás architektúrája

ebXML TA kk 39