E-Business alapfogalmak

E-Business alapfogalmak

Elektronikus szolgáltató rendszerek2005. szeptember, Sopron

Gönczy LászlóBME-MIT

Sopron, BME MIT 2005. Elektronikus szolgáltató rendszerek 2

Miről lesz szó?

Tartalomjegyzék

E-Business fogalmak, kategóriák

B2B modellek

E-Business referenciamodell

Mennyiségi analízis

Felhasználói modell


Mi az E-Business?

• „The use of information and communication technologies to perform business functions”

• Több, mint az elektronikus kereskedelem• „Business as usual”• Keresés, értékelés, logisztika, fizetés,

autentikáció, stb.• E-Marketplace:

– Horizontális: egy beszállítói lánc– Vertikális: egy iparág


E-Business „hamburger”Economics

Business intelligence

Web-based applications

Software engineering


E-Marketplace


E-Business kategóriák• Business-to-Consumer (B2C)

– cégek és egyéni vásárlók

• Business-to-Business (B2B)– cégek közti folyamatok, beszállítói lánc

• Consumer-to-Consumer– pl. Web aukció, p2p jellegű folyamatok

• Government-to-Business– pl. adófizetés, közbeszerzési eljárások

• Government-to-Citizens– pl. segélyek igénylése, kifizetése


B2B modellek

VEVŐK ELADÓKAggregator

Community

AuctionHub

Content

dinamikusan változó árképzés

közvetítő spec. területen v. folyamatban

egyenrangú partnerek (pl. OpenSource fejlesztés)

tartalomszolgáltató(pl. álláskereső)összegyűjti a beérkező

kéréseket és az elérhető szolgáltatásokat


B2B modellek csoportosítása a résztvevők száma szerint

E-markets

Változó terminológia, nincs „szabvány” elnevezés


„Sell-Side Hub” elképzelés


E-Business referenciamodell

Üzleti nézet

Technológiai nézet Belső metrikák

Külső metrikák

Funkcionális modell

Üzleti modell


Erőforrás modell

Keretrendszer: üzleti folyamatok

mennyiségi analízis

pl. bevétel/idő

CPU igény


Üzleti modell• Leírók: üzleti folyamat jellemzői• Üzleti modell fajtái

– online megrendelés– online aukció– tartalomszolgáltató portál– elosztó (disztribútor, pl. félkész terméket árul cégeknek)– szolgáltató (pl. bank)– kiadványok megjelentetése (publishing), stb.


Üzleti modell


Erőforrás modell


Funkcionális modell• Az üzleti folyamat felbontása részegységekre (top-

down technika)• A folyamat lépései (activities) megfelelnek a Webes

alkalmazás által nyújtott szolgáltatásoknak (oldalak)• Lehetővé teszi a navigációs struktúra felírását (melyik

oldalról hova lehet eljutni)


Üzleti modell


Erőforrás modell


Online aukció Use-Case diagram

Setting up a Particular auction

Buyer and Seller Registration

Scheduling and Advertising

Trade Settlement

Bid Evaluation and Auction Closing

Bidding

Customer


QoS követelmények• megbízhatóság, biztonság, skálázhatóság,

kapacitás, ár• Tipikus kérdések:

– mennyi vásárlót vesztünk x idő szolgáltatáskiesés esetén– mennyivel növeljük a sávszélességet, ha multimédiás tartalom

kerül az oldalra– mennyi bevételt hoz a rendszer óránként

• „8 mp” ökölszabály : az átlagos vásárló 8 másodperc várakozás után más szolgáltatást keres

• A rendszer kiszámíthatósága elsődleges fontosságú!


A mennyiségi analízis lépései

Szerverarchitektúra

Szerverteljesítménymérés

Felhasználóiviselkedésjellemzése

TerhelésprofilTeljesítménymodellTeljesítménymérés

Terhelésprofilváltozásának

becslése

Szolgáltatásteljesítményének

becslése

1

7

6 5 4

3

28



• Előfeltétel: üzleti folyamat modellje célokkal/metrikákkal

• 1. Szerver architektúra meghatározása– Milyen szerverek vannak, ezek hogyan kapcsolódnak

egymáshoz, milyen operációs rendszert használnak, milyen hardveren futnak, mennyire skálázható a rendszer, stb.

• 2. Teljesítmény mérése– Kulcsfontosságú lépés, különböző „referenciapontokban”

kell mérni (hálózat különböző pontjai, különböző időszakok)– Tranzakciós és szerver log fájlok alapján– Napi letöltések átlagos száma, az oldal bevétele egy adott

időszakban, csúcsterhelés / átlagos terhelés



• 3. Felhasználói viselkedés leírása– Vásárlói csoportok elkülönítése (sokat keres az

oldalon/keveset vásárol, ritkán nézi az oldalt, de akkor vásárol, csak akciók idején látogatja az oldalt, stb.)

– Cél: tipikus szekvenciák felismerése, navigációs minták felírása, az egyes műveletek számának/gyakoriságának meghatározása

• 4. Terhelési profil meghatározása– Erőforrás modell paramétereinek meghatározása a

felhasználói viselkedés modellje alapján – teljes (aktuális) külső terhelés



• 5. Teljesítmény modell felírása– Formális modellanalízis pl. sorban állási modellek alapján

(Queueing Networks, QN)– Cél: olyan modellt alkotni, amivel követni tudjuk a változásokat

(a terhelésben vagy az oldal architektúrájában)

• 6. Teljesítmény mérése– Bemenő paraméterek meghatározása a modellalapú

vizsgálathoz

• 7. Terhelés változásának becslése– Különleges időszakok terhelése (karácsony, hirdetési kampány,

stb.)– Forgalom „mintáinak” felírása, löketek (burst) nagysága



• 8. Szolgáltatás teljesítményének előzetes becslése– a teljesítmény modell és a terhelés előrejelzés alapján

keressük a leginkább költséghatékony architektúrát


Felhasználói, terhelés és erőforrás modellek


Terhelés modell

Erőforrás modell

A felhasználói viselkedésre vonatkozó kérdések

Architektúra és rendszer konfiguráció változásaira vonatkozó kérdések

Metrikák:- bevétel/idő- válaszidő- áteresztőképesség


Online aukció Use-Case diagram

Setting up a Particular auction

Buyer and Seller Registration

Scheduling and Advertising

Trade Settlement

Bid Evaluation and Auction Closing

Bidding

Customer



• Felhasználói modell– navigációs minták: felhasználhatók a későbbi terhelés

előrejelzéséhez (mi történik, ha hirtelen több felhasználó jelenik meg, többet keresnek, stb.)

– eszköz: Customer Behavior Model Graph (CBMG) , Customer Behavior Model Statechart (CBMS)– terhelési paraméterek meghatározása: ha csak a jelenlegi

terhelési modell felírása a cél, elég egy kevésbé részletes felírás

– eszköz: Customer Visit Model (CVM), kevésbé részletes, nem használható előrejelzésre

– mindig egy session-t vizsgálunk (azonos felhasználótól egy látogatás alatt érkezett kérések sorozata )



• Terhelési modell („Terhelés” előadás)– terhelés intenzitása (pl. tranzakciók indításának

gyakorisága)– egyes szolgáltatások erőforrásigénye (I/O műveletek, CPU

használat, hálózati adatátvitel, stb.)

• Erőforrás modell („Kapacitástervezés” ea.)– a konkrét erőforrásokra jutó terhelés– hasznos a teljesítmény paramétereinek meghatározásához

(válaszidő, áteresztőképesség, stb.)– felhasználható előrejelzéshez (mi történik, ha megváltozik a

rendszer HW/SW architektúrája, gyorsabb processzort, más operációs rendszert használunk, stb.)


Felhasználói modell – CBMG• Irányított gráf az oldalak közti lehetséges átmenetek

és valószínűségeik ábrázolására• n csúcs, ahol

– 1. csúcs: Entry állapot, absztrakt belépési pont, minden felhasználó innen indulide nem tér vissza

– n. csúcs: Exit állapot, absztrakt kilépési pont, a folyamat vége (nem mindig ábrázoljuk explicit módon)

– a többi csúcs megfelel a felhasználó által elérhető szolgáltatásoknak (oldalaknak)

• élek: az oldalak szerkezete határozza meg a csúcsok közt lehetséges átmeneteket


Üzleti modell


Erőforrás modell


CBMG meghatározása

• Statikus CBMG: oldalak és köztük lévő lehetséges átmenetek– az oldalak által nyújott szolgáltatások meghatározása

(pl. Login, Register, Add Item, Remove Item, Pay, Get Quotes, Download, Subscribe, stb.)

– a szolgáltatások halmazának finomítása – az infrastruktúrát különböző mértékben terhelő szolgáltatásokra (pl. Download szétválasztása Download Audio, Download Video szolgáltatásokra)

– lehetséges átmenetek meghatározása – az oldalak megjelenítésének vizsgálatával (linkek, formok, menüpontok, stb.)


Felhasználói modell: CBMS

• Customer Behavior Model Statechart• UML állapotdiagram• Hasonló információt hordoz, mint CBMG, de

mindezt szabványos módon jeleníti meg• Állapotok: az oldal funkciói (állapotai)• Lehetséges átmenetek: rendszer modellje

alapján• Átmenetekhez valószínűség tartozik

(dinamikus viselkedés)– meghatározás: „Terhelés” ea.


Felhasználói viselkedés állapotdiagram modellje

Browse

Search

Home

Pay

Register

Login Add to Cart

Select

[ 0.15 ]

[ 0.7 ]

[ 0.15 ]

[ 0.25 ]

[ 1.0 ]

[ 0.05 ]

[ 0.05 ]

[ 0.2 ]

[ 0.3 ]

[ 0.05 ]

[ 0.05 ] [ 0.2 ][ 0.1 ]

[ 0.25 ]

[ 0.3 ]

[ 0.2 ]

[ 0.3 ]

[ 0.1 ]

[ 0.1 ]

[ 0.1 ]

[ 0.6 ]

[ 0.3 ]

[ 0.2 ]

[ 0.25 ]

[ 0.2 ]

[ 0.1 ]

[ 0.1 ]

[ 0.1 ]

[ 0.35 ]

[ 0.35 ]

[ 0.1 ][ 0.4 ]

[ 0.5 ]

[ 0.1 ]

[ 0.2 ]

[ 0.25 ]

[ 0.2 ]


Felhasználói viselkedés vizsgálata

• Dinamikus CBMG ill. CBMS alapján különböző mérőszámokat határozhatunk meg:– Hits/sec: az oldalról letöltött objektumok száma (képek,

bannerek is)– Page View/Day: adott oldalt hányszor nézték meg– Click-throughs: hányan néztek meg egy adott hirdetést– Unique Visitors: hány különböző látogató volt egy adott

időszakban



• További mérőszámok (felhasználói modell és egyéb statisztikák alapján):– Revenue Throughput: az oldal által elért átlagos bevétel

– Potential Loss Throughput: mennyibe kerül a szolgáltatás kiesése egy adott időszakban

– Visit Ratio: átlagosan hányszor vesznek igénybe egy adott szolgáltatást (egy session alatt)

– Buy to Visit Ratio: átlagosan hányszor vásárolnak egy session alatt (tényleges eladási tanzakció)

– Average Session Length: egy session átlagosan hány szolgáltatást vesz igénybe (nem időt mér)

– mindezen mérőszámok változása, ha a bemenő paraméterek megváltoznak (pl. egyes átmenetek valószínűségei)



• Az előbbi példából kinyerhető adatok :– Buy to Visit Ratio (BV): Pay állapot előfordulásának várható

értéke, k [ P(i,j)] az összes lehetséges Entry-Pay útra (k darab), BV értéke itt 0.058 (5.8 %)

– Végrehajtott eladási tranzakciók száma: ha naponta 100000 látogató (session) van, akkor átlagosan 100000*0.058=5800

– Átlagos session hossz (average session length): az állapotok átlagos előfordulásainak összege, itt. 7.998 (Exit és Entry állapotok előfordulási gyakorisága mindig 1, itt nem számítanak)

– mindezen adatok kiszámolhatóak más átmeneti valószínűségek esetén is (pl. ha megnő a keresés után vásárlók száma)


Customer Visit Model (CVM)

• CVM: különböző típusú felhasználók viselkedését jellemző vektorok (melyik állapotban hányszor járt)

• A felhasználók csoportosítása cluster technikákkal történik, ld. „Terhelés” ea.

• Nem jelzi az egyes állapotok közti átmenetek gyakoriságát, nem jó előrejelzésre

Session1 Session2 Session3Home 1 2 3

Browse 4 8 4Search 5 5 3Login 0 1 1Pay 0 0 1

Register 0 0 1Add to Cart 0 2 1

Select 3 3 2


Session azonosítás

• Cookie-k használatával– szerver generál egy ID-t, amit a kliens minden kéréssel

elküld, az kliens mellett az alkalmazás állapotát is tárolhatja (pl. bevásárlókocsi)

• Autentikációs mechanizmusok, rejtett mezők HTML oldalak formjaiban, dinamikus URL-ek, stb.

• Szerver logok alapján, várakozási küszöbérték (threshold) használatával– ha ennél hosszabb a szünet két kérés (request) elküldése

közt, akkor két külön session, bővebben „Terhelés” ea.


Client/Server Interaction• Server-Oriented C/S Interaction:

– a kliens egy szerver folyamattal kommunikál, ami megvalósít bizonyos szolgáltatásokat, a kliens egy szerver csonkkal (stub) kommunikál, a szerver tárolja az adatokat

– Remote Procedure Call jellegű folyamatok

• Object-Oriented C/S Interaction:– a szolgáltatást objektumok valósítják meg, a kliens ezeknek a

metódusaival kommunikál, adat az objektumoknál

– Object Broker jellegű rendszerek (mint CORBA)

– átlátszó, de lassabb

• Általános modell:– szerver: szoftver entitás, amely a kliens kéréseit kiszolgálja


C/S Interaction Sequence Diagram (CSISD)

• Szekvenciadiagramok minden lehetséges esetre• Objektumok: kliens és a különböző szerverek

(erőforrások)• Nyilak: üzenetküldés• Üzenetek: [p, m] párok, ahol p az üzenet küldésének

valószínűsége, m a mérete (byte)– pl. [0.05, reject_message]: 5% valószínűséggel reject_message

méretű üzenetet küldünk

• Minden lehetséges végrehajtási szekvencia kliensből indul ki és kliensben végződik

• CSID: C/S Interaction Diagram– a szekvenciák összessége


CSISD példa 1.

• Kliens kér valamilyen adatot a Web szervertől, 3 lefutási lehetőség

• 1. eset: A Web szerver túlterhelt: elutasítja a kérést

Kliens Web szerver

[1.0, request_message]

[0.05, reject_message]


CSID példa 2.

• 2. eset: A Web szerver továbbküldi a kérést valamilyen alkalmazásnak (alk. szerver), az alkalmazás cache-ből visszaadja az adatot

Kliens Web szerver Alkalmazás szerver

[1, request_message]

[1.0, reply_message]

[0.95, request_data]

[0.2, return_data]


CSID példa 3.• 3. eset: A Web szerver továbbküldi a kérést, az alkalmazás

lekérdezést hajt végre az adatbázisszerveren, majd visszaadja az adatot

Kliens Web szerver Adatbázis szerver

Alkalmazás szerver

[1, request_message]

[0.95, request_data]

[0.8, query_message]

[1.0, query_answer]

[1.0, return_data]

[1.0, reply_message]


CSISD elemzése

CSISD alapján megválaszolható kérdések:– mennyi a lokális hálózat forgalma, ha minden szerver

ugyanazon a LAN-on van? (p*m) minden szerverek közti üzenetre

– Mi történik, ha a Web szervert leválasztjuk?

(Web szerver:LAN1, többi LAN2)– (Szerver oldali) hálózati késleltetés meghatározása

sávszélesség és üzentméret alapján– Milyen lesz a teljesítmény, ha minden szerver ugyanazon a

gépen fut?

E-Business rendszerek modellezése

Elektronikus szolgáltató rendszerek2005. szeptember, Sopron

Gönczy LászlóBME-MIT


A modellek kapcsolata


Terhelés modell

Erõforrás modell

A felhasználói viselkedésre vonatkozó kérdések

Architektúra és rendszer konfiguráció változásaira vonatkozó kérdések

Metrikák:- bevétel/idõ- válaszidõ- áteresztõképesség


Erőforrás szintű terhelés meghatározása

R: adott erőforrás

F: funkciók halmaza

E[terhelésR] =|F|(gyakoriságF*E[terhelésF,R])

közgazdasági (nem inf.) mérték

informatikai (műszaki) mérték


Rendszer modell meghatározása

Használati esetek: Use-Case diagram

Forgatókönyvek: szekvenciák

Összesített állapot diagram

UML alapú tervezés


Web Szerver

Online könyvkereskedés

Vásárló

Könyv böngészéseÁltalános információk

Bejelentkezés

Regisztráció

Fizetés

Bevásárlókocsi

Keresés

Online könyvesbolt Use-Case diagramja


„Könyv böngészése” Use-Case forgatókönyvei

Keresés az Kliens "Könyv böngészése" oldal adatokban

Könyv adatok lekérése

browse

reply

request

return from cache

reply

query

answer

return from database

Könyv adatok lekérése

W A

D

W = Web SzerverA = Alk. SzerverD = Adatbázis Szerver


„Könyv böngészése” Use-Case forgatókönyvei 2.

Kliens "Könyv böngészése" oldal

"Bevásárlókosár" oldal

add

Bevásárlókocsiba kerül a könyv

W W




"Keresés" oldal

search

Másik könyv keresése

W W




Kilépési oldal

exit

Kilépés

W W


Összesített állapotdiagram

Browse

Search

Home

Pay

Register

Login Add to Cart

Select



• Várható érték jellegű kérdések• Pl. milyen gyakran vásárolnak

– a „Pay” állapot várható értéke• Milyen hosszú egy lekérdezéssorozat

– úthosszak várható értéke• A modellhez rendelhetők valószínűségek

– becslés– mérés– szimuláció alapján


Üzleti modell


Erőforrás modell


Várható érték meghatározása

Kibővített Use-Case diagram

Kibővített szekvenciák

Kibővített állapot diagram

Valószínűségek- haszn. esetekhez- forgatókönyvekhez- elágazásokhoz


Használati esetek súlyozása• Use-Case diagram súlyozása

– minden esethez előfordulási valószínűség• Közgazdasági jellegű becslés

– Mi történik, ha megnő az oldalon böngésző vásárlók aránya?

Könyv böngészéseÁltalános információk

Bejelentkezés

Regisztráció

FizetésBevásárlókocsi

Keresés

0,2 0,15

0,10,15

0,25

0,050,1


Szekvenciák súlyozása

• Esetek forgatókönyveinek súlyozása– minden forgatókönyvhöz valószínűség

• A forgatókönyvön belüli elágazások súlyozása– minden elágazáshoz valószínűség

• Eredmény: súlyozott állapotdiagram


Súlyozott állapotdiagram

Browse

Search

Home

Pay

Register

Login Add to Cart

Select

[ 0.15 ]

[ 0.7 ]

[ 0.15 ]

[ 0.25 ]

[ 1.0 ]

[ 0.05 ]

[ 0.05 ]

[ 0.2 ]

[ 0.3 ]

[ 0.05 ]

[ 0.05 ] [ 0.2 ][ 0.1 ]

[ 0.25 ]

[ 0.3 ]

[ 0.2 ]

[ 0.3 ]

[ 0.1 ]

[ 0.1 ]

[ 0.1 ]

[ 0.6 ]

[ 0.3 ]

[ 0.2 ]

[ 0.25 ]

[ 0.2 ]

[ 0.1 ]

[ 0.1 ]

[ 0.1 ]

[ 0.35 ]

[ 0.35 ]

[ 0.1 ][ 0.4 ]

[ 0.5 ]

[ 0.1 ]

[ 0.2 ]

[ 0.25 ]

[ 0.2 ]


Várható értékek meghatározása mérés alapján• Online: monitorozó eszközök

– hálózat– szerver

• Offline: Szerver logok elemzése– adatbázis– web szerver

• Mérési egység: session– egy felhasználótól beérkező– összetartozó kérések sorozata

• A rendszer modell paraméterezése a kapott értékekkel


Session azonosítás

• Cookie-k használatával– szerver generál egy ID-t, amit a kliens minden kéréssel

elküld, az kliens mellett az alkalmazás állapotát is tárolhatja (pl. bevásárlókocsi)

• Autentikációs mechanizmusok, rejtett mezők HTML oldalak formjaiban, dinamikus URL-ek, stb.

• Szerver logok alapján, várakozási küszöbérték (threshold) használatával– ha ennél hosszabb a szünet két kérés (request) elküldése

közt, akkor két külön session, bővebben „Terhelés” ea.


Várható érték szimuláció alapján

• Szimulációs eszköz: Holosofx• Pl. egységnyi költség minden lépéshez

– várható költség = várható úthossz• Pl. egységnyi költség „Pay” állapothoz

– várható költség =vásárlások várható értéke• Szimuláció az analízis későbbi lépéseinél

(kapacitástervezés, terhelés becslés) is

• mérés szórása ~ (mérések száma)½


Mérőszámok meghatározása

• Súlyozott modellek alapján• Buy to Visit Ratio:

– Pay állapot várható értéke• Átlagos session hossz

– állapotok várható értékeinek összege• Mindezeket kiegészítjük egyéb

(közgazdasági, statisztikai) adatokkal

üzleti metrikák


Üzleti jelegű metrikák

• Átlagos bevétel (Average Revenue)– Buy to Visit Ratio * Average Amount

• Átlagos bevétel / idő - üzleti „áteresztőképesség”, Revenue Throughput– ( Number of Session * Average Revenue) / Time

• Adott hosszúságú leállás miatti bevételkiesés– Revenue Throughput * Down Time


Üzleti modell


Erőforrás modell


Erőforrás jellegű metrikák

• A funkcionális mérőszámokat kiegészítjük erőforrás felhasználásra vonatkozóakkal

• Pl. szekvenciadiagram + üzenetméretek– hálózati forgalom

• Pl. állapotdiagram + erőforrások– átlagos adatbázis elérés, stb. Funkcionális modell

Üzleti modell


Erőforrás modell

Documents

E-Business alapfogalmak