eBusiness: 8. ICT komponensek az eBusiness-ben

1. E-Gazdaság – B2C – B2B – eVállalat – e-IA – Üzleti komp. – eICT komp. – A siker eBusiness: 8. ICT komponensek az eBusiness-ben PTE KTK GINFO szak Dr. Dobay Péter2010 őszi félévin: IBM WebSphere „…Our goal is not to be a visionary, but to get people to take advantage of what technology is available today.” Scott McNealy, CEO, Sun Microsystems

2. Következik: 6. Az e-Vállalkozás architektúrája 7. Az eVállalkozás ÜZLETI komponensei 8. Az eVállalkozás ICT FIZIKAI komponensei 8.1. Kliens oldal 8.2. Szerver oldal 8.3. Szabványok, eszközrendszer

3. The ICT layers of an eBusiness model

4. Az előrehaladás: Az eVállalat felépülésének menete Módszertani elvek, architektúra Az eVállalat „logikai” architektúrája Az eVállalat „üzleti” komponensei Az építést lehetővétevő komponensek Az eVállalat „ICT - fizikai” komponensei Az üzleti és„technikai” eredmény Siker, vagy kudarc…

5. A technológiáról • A dolog nem abban áll, hogy „Sun, vagy MS, vagy IBM, vagy ORACLE” – van még 100 • Az eddigi „felsőszintű”, absztrakt modellekből működő rendszert kell csinálni • Ehhez kellenek standard technológiák és élenjáró, innovatív technikák • Azt láttuk: gyorsabb, olcsóbb, adaptív alkalmazásokkal kell bevezetni az eB-t. Ehhez azonban van egy adott infrastruktúránk, ráadásul a partnerek IA-ját (szállítók, vevők) csak áttételesen (vagy sehogy se) tudjuk befolyásolni! • Szinte mindenhol hatalmas, elosztott hozzáférésű rendszereket találunk – ezekben az alkalmazás-fejlesztés eltér az eddigiektől • Hihetetlenül heterogénné váltak a vállalati eszközparkok • A fentiek miatt az új alkalmazások IA-ja kötelezően integráció-képes, és adaptív kell legyen – általános szabvnyok, Open Standards, OSF, Object Management Group OMG, „3-O” Open Source, Open Standards, Open Access, stb. • Sok szállítóra kell tudni támaszkodni, akár egy időben – ez biztonság is! • Hiány van szoftverfejlesztőkből, akik az új architektúra-építési technikákat (objektum-könyvtárak, SOA) valóban hasznosítani tudják • A komponens-alapú rendszerépítés („Plug & Play”) a desktop szinten kb. összeállt: drag & drop technikák, diagramrajzolás, képek kezelése, rajztechnikák, formok használata, szövegkezelés, keresések, prezentációs elemek) – node a tényleges kemény osztott alkalmazások szintjén még nem…

6. A technológiai és az üzleti szint • Amit az üzleti szinten megfogalmaztunk, azt kell összebarkácsolni, egyenként: alkalmazási szabályrendszer megvalósítása, az integráció és osztott jelleg kialakítása, az adatkezelés és a hálózat-menedzselés. • Alkalmazási szabályrendszer: tipikusan C/S háttért igényel, egy keretrendszert, amiben karban lehet ezeket tartani • Integráció/distribution: szerver-oldali megoldások • Adatkezelés: minden szint: kliens, adatbázis-szerver, alkalmazási szerver, integrációs szerver • Hálózat: alkalmazási szerver, integrációs szerver (Enterprise Application Integration EAI)

7. Láttuk: Az eVállalat „Technológiai modelljének” logikai szintje • eAlkalmazások terjesztése, integrálása • alkalmazás-szerverek köre • elosztott architektúrák tervei • technológiai komponensek • middleware megoldások- integrációs szoftverek EAI • eAlkalmazások szabályai • üzleti logika, előírások • üzleti objektumok lajstroma • „szabály-tudásbank” • alkalmazások logikai váza • alkalmazások komponensei • használható keretrendszerek • eNetworks • Hálózati biztonság alapelvei, technikája, garanciái • titkosítási eljárások • connectivity megoldások • Rendszer-menedzsment • eAdatkezelés • alkalmazásokhoz szükséges állományok • adatkezelési megoldások • Adattárház megoldások • örökölt állományok kérdései • ERP/MRP adattárak kérdése Az eAlkalmazásokkialakított logikai architektúrája

8. A feladatok megosztása Kliens-komponensek E-Alkalmazás szabályrendszere eB szerver komponensek Az alkalmazás diszribúciója / integrálása Alkalmazási keretrendszer Alkalmazás-szerver E-Adatkezelés E-Hálózatkezelés Alkalmazás-integrációs szerver, EAI

9. Az architektúra elemei • Kliens-oldali komponensekFelhasználói felület kialakítása. Minimális alkalmazási logika megjelenítése. Navigációs eszközök létrehozása. Üzenetkezelés a szerverek felé. Példa: rendelés összeállítása • Szerver-komponensekAz üzleti logika, eljárások megvalósítása. Példa: egy rendelés menete (WF), adat-ellenőrzése, a fenti form-ban szükséges adatok lekérése, stb. Más szerverek terhelésének szabályozása, menedzselés, statisztikák, stb. • Alkalmazás-szerverekAz alkalmazás kiszolgálása: futtatás, eljuttatás minden helyre a hálózaton, skálázhatóság biztosítása, megbízhatóság, ellenőrzések. Példa: online üzletben az online vásárlók számától függő kiszolgálás, kapacitások menedzselése. A szerver fizikailag hostolhat kliens- és szerver-oldali komponenseket, vagy az alkalmazási keretrendszer egyes elemeit.

10. folytatás 4. Az alkalmazási keretrendszerAz üzleti funkcionalitások megjelenítése: mit lehet megcsinálni itten? A teljes rendszer látszik: felhasználók kezelése, keresések, munkafolyamatok, fizetés, biztonság, stb. Ezek nagy objektumok, amelyek sok kisebb komponens megmozdítását végzik, a teljes alkalmazási környezetet láthatóvá teszik a felhasználók és a menedzsment számára. 5. Vállalati szintű integrációs keretrendszer (EAI)A meglévő rész-alkalmazások, adatállományok, speciális kismegoldások, alkalmazási kész csomagok Web-szintű integrálását végzi el. Ez lehet standard middleware keretrendszer, vagy ennek továbbfejlesztése. A standard MW rendszerek (pl SUN One Middleware, Fusion Middleware, Tuxedo, Tivoli, stb.) többféle alkalmazás között képesek összeköttetést teremteni - a lényeg az, hogy az alkalmazási interfész gördülékenyen menjen, miközben alatta súlyos egyeztetések, konverziók, transzferek folynak, biztonságosan, ellenőrzötten, naplózással, stb.

11. Egy tipikus middleware: Tuxedo • Middleware: olyan szoftvercsomag, ami segít „összeragasztani” több létező, futó alkalmazást, vagy legalább „közvetít” közöttük. A leggyakoribb eset adatbázisok kapcsolatteremtésének megoldása, így alkalmazások más adatbázist tudnak használni. Magát a MW-építési folyamatot Enterprise Application Integration-nak nevezzük EAI • Tuxedo (Transactions for Unix, Enhanced for Distributed Operation) egy MW termék, ami üzenet-alapú kommunikációs rendszert hoz létre különböző OS platformok és adatbázisok között. A Tuxedo az OS kiterjesztéseként funkcionál: használható végrehajtásra és fejlesztésre egyaráént. A Tuxedo jól használható eBusiness, eCommerce OLTP rendszerek létrehozásánál és adminisztrációjának felélpítésekor, • Fejlesztője 1970 (!) óta az AT&T volt, átvette a Unix System Laboratories (USL), majd megvette a Novell, végül a BEA Systems. • A Tuxedo három funkciója: • MW: kapcsolatokat működtet kérés-válasz (RR) alapon szerver-kliens közöt • TP monitor: transaction processing kezdeményezése, monitorozása, befejezése • Distributed TP monitor: különböző rendszerek és adatbázisok felett zajló tranzakciók menedzselése • Példák: The Gap, E*TRADE, és Hong Kong International Terminals repülőtér nagy volumenű tranzakciók összehangolására használják

12. 8.1. A kliens-oldal: a front-end alkalmazások • A kliens munkája egy „folyamat”: olyan alkalmazás, ami a szerveren futó alkalmazáshoz kéréseket küld, majd fogadja és megjeleníti a válaszokat • A kliens-alkalmazás a felületet kezeli, validálja az adatbevitelt, továbbítást végez, esetleg egy kis üzleti logikát használ fel • eAlkalmazás esetén platform-függetlennek kell lennie: a user a Weben jön befele az alkalmazásba • Alapvetően felhasználó-orientált kell legyen (nyelv, terminológia, stílus, design, stb.) • Vékony- és vastag-kliensekre kell felkészülni: ez a megvalósított funkcionalitás mértéke, böngésző helyett spéci alkalmazás fut, dedikált platform, stb. • A „kliens-oldali komponensek” lehetővé teszik ilyen kliens-felületek felépítését, gyorsan, adaptálható-flexibilis módon, újra-felhasználhatóan, inter-operabilis módon az ipari standardokat tekintve • Két fő architektúra ezen a szinten: Java Beans (Sun) és ActiveX (MS)

13. Domináns kliens-oldali komponensek Hagyományos C/S alkalmazásban a kliens megjelenítő logikát (ablak és vezérlések), üzleti logikát (algoritmusok és üzleti szabályok) és adatmanipuláló logikát (DB-kapcsolatok, SQL lekérdezések) tartalmaz ez bonyolult klienst igényel! A mai cél a többrétegű architektúra: a kliens csak megjelenítő logikát tartalmaz, az üzleti és az adatelérési logika különálló komponensekre van osztva, egy vagy több szerveren . • JavaBeansPlatform-független, OS független, komponens-alapú architektúra a Java JVM platformra – így hordozható, akár PDA-kra, mobilokra! Alapvetően a kliens-oldalra, a felhasználói interfész kialakítására való.Egyre többen térnek át az interfészekkel 100% Java alapra, ami felgyorsítja a fejlesztéseket. • ActiveX vezérlőkA MS komponens-technológiája, disztributive alkalmazások építésére. Nyelv-független rendszerek. Az MS alkalmazások könnyen továbbvihetők a webre: a C/S alkalmazás „becsomagolható” ActiveX vezérlésekbe, ez gyorsabb, mit újrafejleszteni Java –ban…Az MS Active Server Technology részeként továbbmegy a szerver-oldalra.

14. 8.2. A szerver-oldal komponensei • A szerver-oldali folyamat egy program, egy alkalmazás futtatása, ami az adott kérésre elvégez egy feladatot (task). • A lépések: a kérés fogadása, adat-visszakeresés, update, adatkezelés integritásának biztosítása, üzenetküldés. • Egyes megvalósítások némi üzleti logikát, közönséges alapfeladatokat szolgáltatnak • A szerver-alkalmazás feladata az alkalmazások használatának összehangolása, ezek kommunikációjának megvalósítása, terhelések kiegyenlítése, skálázhatóság biztosítása, stb. eBus esetén komplex hálózati szolgáltatásokat kell biztosítani! • A komponensek futhatnak az OS szerverén, a hálózati szerveren, vagy külön gépen. • Az eBus esetén a speciális üzleti logikát ez a szint adja: amit az eAlkalmazás „Üzleti modelljében” láttunk, azt itt kell megvalósítani. Ide kerülhet az alkalmazási keretrendszer egy része, alkalmazási komponensek, MW részek, és persze rendszerszintű szolgáltatások (kommunikációs rendszer, integrálás, adattovábbítások, stb.)

15. Szerver-oldali technológiák • CORBA Common Object Request Broker ArchitectureAz eAlkalmazások kihívásai: hatalmas user-oldali igények, és integrálási kötelezettség az ERP/EIS-sel. Az ORB egy middleware megoldás, objektumok kommunikációjára, származzanak ezek bárhonnan. Az OMG által támogatott megoldásnál az „ORB-kompatibilis eAlkalmazás” kérést küld, az ORB ezt befogadja, megkeresi a hálózaton azt az objektumot, ami ezt ki tudja szolgálni, átadja a paramétereket, végrehajtatja a metódust, majd visszaküldi a választ. A kliens NEM VESZ TUDOMÁST arról, hogy hol van a végrehajtó alkalmazás, milyen platformon, milyen nyelven, stb – ez a „brokering” lényege! • COM/DCOM Distributed Component Object ModelA COM egy Microsoft specifikáció és implementáció (API, Appl Programming Interface). A felhasználható objektumokat a COM-on keresztül lehet kommunikációra bírni, ha így fejlesztünk – egy adott gépen! MS környezetek számára ez az ideális megoldás, együtt az MTS-sel. A DCOM ennek továbbfejlesztése heterogén, disztributív környezetekre.Ez akkor jó, ha bizonyos alkalmazások fizikailag máshol vannak, pl. egy LAN szegmensen sok apró alkalmazás ül, terhelve a hálózatot, vagy valahol egy gyors gépen nagyobb elemek vannak letéve, stb. Ami fontos: az alkalmazások bármilyen nyelven megírhatók – ez fontos a rendszerfejlesztésnél! Alapvető kérdés, hogy mi van, ha baromira felfut a userszám, és/vagy a forgalom: a COM/DCOM mindenképpen a MS-hez köti a fejlesztőt. Ezért az OMG elkezdte szorgalmazni a COM-csatolójú fejlesztéseket is.

16. folytatás • EJB Enterprise JavaBeans: "egyszer megírni, bárhol futtatni" Újrafelhasználható Java komponensek működtetésére ad lehetőséget. Kiterjeszti a JB komponens-modellt az alkalmazás- szerver-oldalra. A SUn filozófia szerint robosztus, nagyterhelésű, hatalmas forgalmú, működés-kritikus biztonságú alkalmazásokat lehet fejleszteni. Támogatja a C/S-től felfelé menekülő, többrétegű alkalmazások fejlesztését.Teljes mértékben független minden platformtól, MW infrastruktúrától: a EJB „konténer” tartalmaz mindent az adott gépen. A komponens-szemlélet lehetővé teszi a független kódolást egy projektben – nem kellismerni mások forráskódját. • OTS Object Transaction ServiceLényegében a CORBA MW megoldás egy komponense, egy „protocol-engine”, ami az objektumok egy halmazát adott tranzakcióra kéri fel („indulj – állj meg”). Önmagában nem áll meg, kiegészítő szolgáltatásokhoz kell kapcsolni. • MTS Microsoft’s Transaction ServerEz lényegében egy termék, a WIn 2000 alatt jelent meg. Csak a MS Internet Information Serve IIS alatt fut, a Win 2000-et teszi osztott környezetben használhatóvá. A DCOM-ot használja különböző platformok összekötésére, nem a CORBA- t. így, ha a fejlesztő beleütközik egy régi rendszerbe, pl. UNIX alapon, akkor bajban van. Sok nyelven használható, ez előny. Maga a komponens-modell ugyanúgy „konténer-elvű”, mint az EJB.

17. Példa: Money Makers értékpapír-tőkeszámla kezelése A Money Makers, egy nagy brókerház, arra használja az Enterprise JavaBeanst, hogy értékpapír-tőkeszámlát kezelő alkalmazási rendszert hozzon létre. Web-alapú önkiszolgáló elektronikus kereskedő rendszert akar szolgáltatni a klienseknek. Egyszerű kliens, osztott objektumú architektúrával valósították meg az alkalmazást mind a brókerek, mind az ügyfelek hatékony támogatásához. Az alkalmazás klienseszközök nagy választékát képes kezelni, köztük asztali munkaállomásokat, webböngészőket, telefonokat, kioszkokat, intelligens aktív kártyákat (smartcards) és egyéb internetképes eszközöket. A kliensalkalmazások különböző protokollok segítségével kommunikálhatnak a tőkeszámlát vezető alkalmazással. A Java kliensek az RMI igénybevételével hívják az alkalmazást. Az RMI a natív Java Remote Method Protocolon (JRMP) vagy az ipari szabványos Internet InterORB Protocolon (IIOP) fut. Nem Java kliensek a CORBA IDL használatával vagy egy COM/CORBA hálózatközi (internetworking) szolgáltatással hívhatják az alkalmazást - mindkett0 IIOP-n fut. Böngészők a HTTP szerveren futó servlettel tehetik ezt meg. A böngésző a HTTP-n keresztül kommunikál a servlettel, a servlet pedig az RMI révén az alkalmazással. A Money Makers először vásárolt egy értékpapírtőke-számlakezelő rendszert a Portfolio Finesse Inc. szoftver-szállítótól. A Portfolio egy adatbázis-szállítótól beszerzett Enterprise JavaBeans szerverre fejlesztette ki az alkalmazást, amely, bár a kliensek számláinak kezeléséhez és a portfóliók szervezéséhez szükséges funkciókat szolgáltatja, nem használja a percnyi pontosságú tőzsdei árakat a számla aktuális értékének a számításához, és online kereskedést sem lehet vele folytatni. A Money Makers elvégezte az értékpapír-komponens testre szabását, hogy az képes legyen kikeresni a legfrissebb részvényárakat egy élő adatbetáplálásból. Ehhez a Garage Enterprises-tól megvásárolt Enterprise JavaBean részvényár-nyilvántartó rendszert használta. A Garage nyilvános használatú Enterprise JavaBeans szerverre fejlesztette ki a komponenst. A Money Makers az online kereskedő funkciót úgy valósítja meg, hogy belefoglalja a meglévő kereskedő rendszert, és azt integrálja a Portfolio rendszerrel, a CORBA segítségével.

18. Alkalmazás-szerver: back-end réteg • Ez egy szolgáltató platform, ami skálázható, megbízható, biztonságos, menedzselhető módon futtatja az alkalmazást – ezek az eAlkalmazás feltételei… • Tisztán elkülönülő réteget valósítanak meg a Web-szerver és az adatréteget kezelő rendszer között. • A kimenet lehet a Web, intranet, Extranet • Sikeres alkalmazás-szerverek: IBM WebSphere Application Server (Open Standards, CORBA alapokon), BEA WebLogic Server (EJB, Java API-k támogatása) • Egy eAlkalmazás szükséges rétegei: • Web-szerver réteg • Alkalmazás-szerver réteg: az alkalmazási logika • Adatkezelő réteg • Az AS feladatai: kapcsolat-menedzselés, állapotok figyelése, session management, üzleti logika futtatása, terhelés-menedzsment, hibakezelés, adatbázis-elérés, tranzakciók menedzselése, adminisztráció, stb. A fejlesztőnek az üzleti logikára kell koncentrálnia, a többit „hagyja másra”.

19. WebSphere’s birth and story • IBM’s product • its roots are in the mid-1990s • based on Java programming language • IBM launched WebSphere in 1998 • gained momentum with on-demand business (2002)

20. WebSphere Goals • integrate all of a company’s existing data • give a Web front-end to all • support for business processes • respond to market fluctuations and new industry supply chain requirements in realtime. • build interactive Web-oriented applications • support business functions needed for e-commerce

21. What is WebSphere?(1) • a set of software products

22. What is WebSphere?(2) • middleware application • trasforms the old business into SOA • is J2EE certified • implements three tier architectures • composed of: • server software • development products this two parts are bundled into packages • The foundation of the software is WebSphere Application Server (WAS)

23. What are its main features?(1) • It works across all of its different operating systems and applications • Unify the company’s management • Modular options: • There are different tools that can be added to WAS • Different tools help the different audiences • Example: • for Web-site developers • for application developers • Four different sizes: • Small • Medium • Large • Super Size A Company chooses the size according to its needs

24. What are its main features?(2) • run code that enables business application • Example: Run many EJBs and Servlet within WAS • realizes multi-tier applications • Example

25. WebSphere Architecture

26. WebSphere’s Architecture example

27. What are advantages? • Business features: • simplifies the attainment of the “time to market” • gives only point of administration • simplifies the communication inside the company

28. Conclusions • IBM is using its size to become the leader • There are other products: • BEA System • SAP • Windows Server System (.Net and Windows Server 2003) [best for the smaller company] • using WS, Don Sloan (Kforce) reduces the time required for its applicant matching process from two or three days to less than an hour • WebSphere costs a lot of money……

29. További alkalmazási keretrendszerek • A fejlesztők problémái az OOP szemléletre való áttéréssel: • A programozóknak hatékonyan kellene használniuk az OOP technikákat – nem „nyelvet tanulni”, hanem szemléletet • Új technológia használata kockázatos. Aki először „tanul”, pocsék rendszereket fog létrehozni… • Az egész így költséges és kockázatos lehet. Kéne valami biztos alap, segítség, ami ezt csökkenti. • A válasz: „framework” rendszerek felkínálása, amelyek adnak valamiféle OOP alapmodellt, alapvető üzleti logikai részeket, amivel neki lehet ugrani egy eAlkalmazás fejlesztésének. Így a fejlesztés egy „keretrendszerben” történhet, egy közös architektúrában, ami segít az integrációt megvalósítani. • IBM San Francisco Project (Java alapon): 3-rétegű architektúrákhoz szükséges újrahasznosítható kódrészletek: Foundation (alapstruktúrák), Common Business Objects (együttműködés megalapozása), majd Core Business Processes (számvitel, könyvelés, megrendelés, raktárkezelés!) • EC Cubed ecWorks: gyorsfejlesztésekhez, kész modulok, interfészek(ecProfiler, ecAdvisor,esWorkRouter, ecTradeMaker, ecDataBuilder)

30. Az EAI folyamat és megoldásai • A rohamosan fejlődő eAlkalmazások sokféle helyen, módszerrel, megoldással készülnek, ezek integrációja előbb-utóbb elkerülhetetlen:Enterprise Architecture Integration • Ráadásul az alkalmazások egy része működés-kritikus, nem leállítható • Forrester Research: a fejlesztők idejének 35%-a köztes-szoftverekre, interfészek programozására megy el! • A kulcs mindehhez: • Standard MW megoldások használata • Distributed OOP megoldások elterjesztése • Régebbi alkalmazásoknál kénytelenek vagyunk interfészek és one-to-one megoldások hegyeit alkalmazni, újaknál illik integrálhatóságot, inter-operabilitást építeni – de így is káosz… • Az EAI a sokféle interfész birizgálása HELYETT egy többszörös hozzáférésű közös interfész-platformot hoz létre (általában két szinten). Minden (új) alkalmazást ehhez kell illeszteni, és akkor nem lesz problémája • Szállítók: CrossWorld, Extricity, TSI Soft Mercator • Példa: SAP ERP integrálása Hyperion BI alkalmazással nem ugyanaz, mint a BAAN ERP integrálása a Hyperionnal…

31. 8.2. ICT szabványos megoldások • A cél: szabványok nélkül nem mehet a fejlesztés, mert nem lesz hatékony és nem lesz karbantartható, továbbfejleszthető • UML (Rational Software: Booch, OOSE /Jacobson, OMT egyesítése): a szoftver-fejlesztés első lépcsőinek standard modellezése. Egy „nyelv”: specifikálás, vizualizálás, szerkezet-építés, dokumentálás, üzleti modell, software és non-software eljárások modellezése. Nagy haszon új eAlkalmazások fejlesztésére. • Privacy & Security: ez volt a legnagyobb akadály a Web-alkalmazásoknál, ezért kellett a Netscape SSL-je, hogy a szerverrel biztonságosan lehessen kommunikálni • PKI: aszimmetrikus „nyilvános kulcsú” titkosítás, 1024-2048 bites kód • Digitális tanúsítványok megoldása: a szerver, a webhely azonosítása • Digitális aláírás: üzenetek biztonságának tanúsítása • WF technikák, WFMC, SWAP: az e-folyamatokra nagyon precízen, tisztán kell felmutatni. www.aiim.org/wfmc WF Mgmt Coalition, vagy Simple Workflow Access Protocol: WF-k egymásközti kommunikációja • XML, 1998: az HTML kiterjesztése, W3C szabvány, platformok közötti adatmozgáshoz a teljeskörú leírás biztosítása: a szövegfolyamot adat-objektummá alakítja, leírja a szerkezetet és elválasztja a megjelenítést (ami az HTML központi kérdése volt). Novell: DirXML directory Services, EDI továbbfejlesztések XML/EDI, cXML for Commerce, stb.

32. Konklúzió • A cél: az üzleti megoldások (egy részét legalább) közös, standard komponensekből kell megépíteni • A kliens-oldali, szerver-oldali, alkalmazási keretrendszer szintű megoldásokat integrálni kell • A szabványok (alakuló) szerepe óriási

33. Bibliography • http://www.ibm.com • http://advisor.com • http://www.redbooks.ibm.com/redbooks/pdfs/sg246176.pdf • http://www.redbooks.ibm.com/redpapers/pdfs/redp3601.pdf