Orientace na služby, klí ové paradigma sou asného softwaru
Budeme diskutovat z ejmé v ci. Opomíjení samoz ejmostí je ale hlavním problémem IT. Opomenutí samoz ejmostí mívá totiž fatální následky. Platí to p edevším pro servisní orientaci
Principy servisní orientace jsou dlouho známé a celkem snadno pochopitelné. Jsou ale práv tím, co opomíjíme, a to i nyní, kdy se stávají vedoucí filosofií sou asného softwaru. Ten se stává sí ový z logického hlediska a musí mít specifickou architekturu (servisn orientovanou architekturu (SOA).
!" Soubor softwarových komponent spolupracujících obdobn jako služby reálného sv ta • Všechny služby jsou stále aktivní • Vy izují požadavky asynchronn (v
principu od více žadatel ) • Požadavky na službu mohou být ve front i v datovém úložišti
Služby a infrastruktura, zajiš ující jejich spolupráci (middleware)
Klí ová role architektury Uskute nitelné požadavky
Management IT
Politika výrobc SW a systémových integrátor
Architektura systému
Vývoj
!"$
%
&
'(
)
• Ai – aplika ní služba UR – rozhraní systému (portál) B - brána
A2 A A3
B
UR B
Middleware
B B
A1 log
UR
#
Staré rozhraní pro A1
+
&,- .
Po et výsledk vyhledávání • Service oriented architecture +software • Dtto +journal • Dtto +ISBN
250000 25000 10000
Mnoho komer ních produkt , r zné definice a r zné varianty podobného p ístupu • Enterprise service bus • Web services, semantic web, … • Composite applications, assembled applications *
-1
• e-komerce (p íklad SO typu aliance) • Informa ní systém státní správy • Informa ní systém globálního podniku • ízení proces (soft real-time) • Spolupráce zdravotnických za ízení • Možná implementace CRM, SCM • Atd. Budeme se zabývat hlavn konfederacemi
/
Konfederace
0
34 !5!+67 4 + 8 9
& 8 - - : : 4 <1: ?: % &
4
= $
:
-
& 1 - ;< & -8 ( 0 > 9 1 ?&1 :;
+ 7@7)!67
0 A : 8 &; : : $ 1 A > ! 1 ?&1$ :0; ( ' 1 ?&1 ? : 9 1 ?&1$'11 : - A (& 8 1: = 1:0 - & 4 = C %D & $0 8 D ' : 9 $ ( ' 1 ?&1$ : - E$ : : 8( 8 08 4 4 B
4 7F
A & 8 : & 8 & 3&$ A 9 ?; &E= 1= ='1 1 ?: : = 0 > > &
3-
$&E=
2
3& 9 1 ?& A ' 1 > 1 ?& $A : Vn jší sv t
IS SW podpora
Neautom atizováno
Koncoví uživatelé
Vn jší sv t
!
Hranice IS
IS Excel
9
IS
Vn jší sv t (jiné IS)
Uživatel (organizace)
• Jiné služby
Vn jší sv t
IS Koncoví uživatelé – p ímo se systémem pracují Uživatelem se míní podnik, který IS využívá GH
Komunikace m že být prost ednictvím zpráv nebo datová, daný systém m že používat obojí IS Sv t IS
IS O p e ra tiv y
IS
H is to ric k á a e x te rn í d a ta
D o t a z y , p ík a z y A k t u á l n í d a ta o p e r a t i v y
P r e s e n ta c e d a t D a t o v ý s k la d M anagem ent J e n u tn á s p o lu p r á c e a p l ik a c í! ! !
P re s e n ta n í a p lik a c e , n a p ík la d E X C E L
N e e l e k t r o n i c k é in f o r m a c e , G ra fik a , W o rd
P r o s t e d k y a n a l ý z y d a t , s t a ti s t i k a a fin a n n í ro z b o ry
Datové rozhraní p es úložišt je typické pro manažerské IS. Umož uje, aby p edávání pokyn bylo inteligentní (nebylo pouhým p ebíráním rozkaz v po adí, jak p ijdou) GG
!A
: :
I
Aby mohly být komponenty velkých systém používány rozumn , musí spolupracovat jako služby – autonomn reagovat na požadavky z r zných zdroj a být používány jako erné sk í ky. To reáln lze dosáhnout jen, tvo í-li virtuální p2p sí . Z hlediska systému nemá žádná komponenta výjime né postavení G
8 Middleware nemusí být Internet, služby nemusí být webovské služby, rozhodující je zp sob spolupráce (asynchronnost). Tendence je k web službám a použití internetu.
G
8 • Spolupráce služeb m že být i dávková/datová • dávkovým exportem a importem dat • p es spole né (virtuální) datové úložišt pln né
p ípadn dávkov
• Spolupráce služeb m že být interaktivní • P ímá vým na zpráv • Aktivní databáze
• N které služby mohou být dávkové (Excel v našem p íkladu) G
!: 9 E8 ?
='1&
'(
1:
• Je b žné, že informa ní systémy komunikují s jinými informa ními systémy. • Informa ní systémy mohou • fungovat jako systémy automatického ízení
(avionika letadla), • dávat rozkazy lidem, • být (do asn ) nahrazeny lidmi, ídit procesy reálného sv ta (v tom p ípad m že ale vzniknout problém dostupnosti dat nebo problém v asnosti odezvy)
GJ
9A 1 -1= AA:
$ :1 1 =
1A= -
• Zm na pot eb
• Globalizace => nutnost a výhodnost
konfederovaných distribuovaných systém v globálních podnicích • Informa ní služby státu, dtto • Spojování produkt r zných výrobc • Další SW inženýrské pot eby, nap . inkrementální vývoj a modernizace, znovupoužitelnost, spolehlivost …..
• Zm na možností technologie, SOA m že být dostate n efektivní • Dostupnost a kapacita komunika ní infrastruktury • Existence programovatelného uživatelského
rozhraní
G#
:
- D&
A
A: & -1 '1
? 'A
? ?"
Co je paradigma • Základní filosofie, techniky, výsledky a postupy daného oboru •
Newtonova mechanika * kvantová mechanika
• Je nutné pro ešení nových problém , • n jak integruje starší paradigmata, • starší paradigmata nesta í v oblasti, pro které je nové paradigma ur eno (Newton v mikrosv t ) • Nové paradigma je obtížné p ijmout lidmi zvyklými na starší paradigmata • • •
Musí je asto nahradit až nová generace P ijetí a vycizelování nových postup trvá roky V technické oblasti je spojeno se zm nami obchodních a manažerských strategií a postup a u technických obor i se zm nami struktury podnik
G*
Problém p ijetí paradigmatu, p íklad Registr aktiv a závazk v R Jak ud lat registr ú t pro kontrolu oprávn nosti žádosti o sociální dávky a podpo it zjiš ování okolností pro poskytování úv r , žádoucí je budoucí rozší ení na dluhy a perspektivn na registraci majetk G/
)D
8
8 E
Sou asný návrh:
Vytvo it centrální databázi ú t a ú ad, který by ji spravoval Pozorování:
Jde o centrální službu v konfederaci (služby jsou IS bank, ú ad , …). U centralizovaných služeb v SOA lze o ekávat potíže (narušení p2p principu) • Náro nost replikace dat a aktualizace seznamu ú t . • Malá flexibilita (co jiný majetek, co dluhy) • Problémy se zneužíváním (kdo použil replikovaná data, nebezpe í zcizení dat) • Vysoké náklady na provoz G2
)D
8
8 E
Lepší ešení:
Vytvo it relativn jednoduchou aplikaci, která se chová jako portál pro lidi i služby mající omezený p ístup ke všem IS bank pro dotazy tvaru: „Kolik má u vás pan X zrovna te pen z/dluh .“ Pro banky je to také jednoduché, v tšinou už mají tém vše implementováno a mohou si ohlídat, kdo se to vlastn ptá Problémy s efektivností jsou nepravd podobné, dotaz musí odpov dný ú edník individuáln iniciovat, takže dotazy nebudou si p íliš asté, a nep edpokládají se komplikovan jší zp soby zpracování dat '?& & A : 8 A &1K K K K- > 1 :0 : - ?& ?& L0 - " H
P íklad II. IS globálního podniku • Globální podnik je tvo en sítí autonomních divizí, které lze prodat nebo které byly nakoupeny • Nutnost spolupráce s IS prom nné množiny obchodních partner pro B2B • Pot eba neustálé modernizace IS • Pot eba používat nové nástroje analýzy dat vyvíjené r znými výrobci • Velmi rozsáhlý soubor koncových uživatel s r znorodými a prom nnými pot ebami a právy
G
D sledky I. • Nakupované divize bývají kupovány se svými IS, které se musí n jaký as používat • Divize je p i prodeji cenn jší, je-li prodávána se svým IS. Ten proto musí mít v rámci podniku jistou autonomii (lze ho odd lit, neprodává se s ním se p íliš mnoho znalostí o celofiremním IS) • Je žádoucí/nutné, aby se p i B2B používaly IS obchodních partner pokud možno bez úprav
Nutnost konfederace, státní správa • Jednotlivé ú ady mají své IS
• Vzniklo historicky • Je politický zájem zachovat samostatnost IS
jednotlivých ú ad • Je to i zájem v cný
Ochrana dat Jasné odpov dnosti IS pot ebují ke své práci –> budou se o n j starat
• Je nutná spolupráce s IS podnik • P ístup ob an k IS ú ad => R znorodé skupiny koncových uživatel , mnoho uživatel
Kdy je nutné použít SO, p íklad státní administrativy 1.
Jednotlivé složky státní správy mají své systémy, které si cht jí pokud možno zachovat • Vložili do nich svoje znalosti, mnoho funkcí se nesmí m nit a
musí se provád t na daném ú ad • Musí ru it za jejich práci a proto jim musí v it, leccos je tajné • Lidé se brání se zm nám, které jim bezprost edn nic nep ináší, zm ny se musí d lat ve spolupráci s nimi • Mocensky se lidé i ú ady snaží zachovat svoji autonomii a svá pracovní místa • Autonomie je výhodná pro získání výhod (známosti mimo ú ad, r zné výhody, provize až korupce) • Je nereálné všechny systémy p episovat znovu (cena, termíny, spolehlivost) a i rekonstrukce nem že mít za cíl monolitické ešení • Nelze p ipustit p ílišnou závislost na jednom dodavateli
Kdy je nutné použít SO, p íklad státní administrativy 1. Modifikace SOA systému jsou snazší, má to mnohé SW inženýrské p ednosti 2. Systém musí být otev ený a spolupracovat s obdobnými systémy (obce a m sta, armáda, IS podnik , zdravotní systémy, IS mezinárodních organizací). Rozsah spolupráce je pro r zné ú ady r zný. Je proto žádoucí použít takovou architekturu, která umožní stejný zp sob spolupráce mezi subsystémy uvnit státní správy i mimo ni J
D sledky II • Je nutno zachovat autonomii IS ú ad • Nelze jinak z politických d vod • Je to výhodné v cn (alespo potenciáln ) • Je to výhodné softwarov inženýrsky
• Je nutné umožnit spolupráci s autonomními IS podnik • Je nutné umožnit p ístup ob an m i IS podnik . To jsou prakticky identické požadavky jako u globálních podnik !!! #
Spole né vlastnosti všech servisn orientovaných systém • Virtuální peer-to-peer spolupráce autonomních komponent (autonomie využití a také vývoje) spolupracujících jako služby masové obsluhy, p2p je nutnou podmínkou, aby se SW komponenty chovaly obdobn jako služby (v tom, co je služba není ješt mezi experty úplná shoda, pro nás autonomní komponenta, peer ve virtuální síti pracující asynchronn ) *
Spole né vlastnosti všech servisn orientovaných systém II Dostupnost n kterých operací jinak obtížn realizovatelných ( áste ný outsourcing, decentralizace, podpora manažerských operací uživatel obecn ) • Výhodné SW-inženýrské vlastnosti (modifikovatelnost, metody oživování, znovupoužitelnost, úspory p i vývoji a údržb ,…) • Použitelnost agilních forem vývoje /
Kdy je nutné použít SO, další d vody • Spolupráce existujících systém , které musí být použity tak, jak jsou z následujících d vod : • nelze je dost rychle p epsat (viz reorg cycle, hned jak •
•
• •
dokon ím, musím za ít znovu) dosavadní uživatelé musí „svým“ službám v it a musí mít p íležitost specifikovat, co pot ebují (feeling of ownership), neradi se u í n co, co jim nezlepšuje práci, jsou ochotni nést odpov dnost jen za to, emu v í uživatelé jsou sami velmi autonomní a v tšina funk nosti jejich systém z stává lokální (CRM, zdravotnictví, ekomerce) politické a mocenské d vody levoty (provize, úplatky, snahy o to, aby nebyl dohled) 2
Kdy je nutné použít SO, technické d vody • Velký systém musí být budován a modifikován po ástech ze softwarov inženýrských d vod • N které operace nelze rozumn impementovat jinak, než v SO (selektivní insourcing a outsourcing, decentralizace ) • Systém sám má charakter spolupráce služeb nebo aplikací (typické pro ízení proces majících charakter služeb), historické p íklady:
• Z ásti p ítomno v systémech psaných v COBOLU • Soft RT, opera ní systémy – obsluha periferií, symetrický
multiprocessing, komunika ní sít H
Výhody servisn orientované architektury • R zné ásti systému asto eší dosti r zné problémy, k jejichž ešení se mnohdy hodí zcela odlišné p ístupy a technologie • R zné ásti systému jsou r zn kritické (nebezpe í ztrát) • R zné ásti systému vyžadují rozdílnou rychlost odezvy, n které mohou být dokonce dávkové • Systém je možné zprovoznit v rozumném ase, s rozumnými náklady • Stávající systémy mohou sloužit nadále bez podstatn jších zm n, lze integrovat produkty t etích stran • Flexibilita G
Další výhody servisn orientované architektury • Autonomie ástí zv tšuje odolnost systému proti výpadk m • Dosavadní uživatelé existujících služeb jim mohou v it, protože se v podstat nem ní. Nemusí se u it p íliš nového a mohou d v ovat i dat m. • Úspory náklad z d vod znovupoužitelnosti, použití produkt t etích stran a snadn jšího vývoje všeobecn @
&: 8
-
9
= : krát
:0 ' =
Dopad na organiza ní hierarchii T T P vodní struktura
ekalo se (šéf u ídí více lidí)
T Obvykle se stalo (decentralizace) Vždy mén hlavn st edního managementu i u n ho zm na profesní struktury (v tší samostatnost šéf divizí) p i decentralizaci
Pro až nyní takový zájem • Informa ní systémy musí být nyní dekomponovány do služeb
• d íve to nebylo ultimativním požadavkem, systémy bylo možné
budovat znovu od po átku, n které komponenty musí být z principu integrovány jako erné sk í ky (IS externích organizací a t etích stran)
• Nebyla vhodná infrastruktura pro všeobecné použití (internet) a výkon hardwaru v etn komunikací • Marketingové d vody, neochota nabídnout zákazník m v tší samostatnost, využití stávajících customizovaných systém , nutnost zm ny obchodní strategie výrobc softwaru • Utajování metodologie SOA jako konkuren ní výhody nebylo možné do nekone na, dnes se stává kontraproduktivní
Pro až nyní takový zájem • Pro mnohé nové paradigma – zm na filosofie, technik, dovedností, nep íjemná nutnost používat existující zdánliv zastaralé aplikace a kombinovat dávkové a interaktivní zp soby práce a navíc i datov a p íkazov orientovaná rozhraní, nové paradigma i pro managementy dodavatel i zákazník ! • Pot eba uživatelsky orientovaného rozhraní služeb => nutnost hlubší spolupráce v tšiny vývojá s uživateli z r zných stup organiza ní hierarchie, probémy s MDA. J
-
:0
4 M 8 8 3 4 @
: : :
E$:0
3&
4 4 O:0 8
:
1 :0
-
4 ) 4 O :> : 6) $ 6 "
8
: :
:9
6 - N "
1$8 :> 1>> -
-
--
8- > :
3&
- $8
E F
& :
#
1
$
Obvyklá architektura aliance, e-komerce A - aplika ní komponenta A A
B
A
A
Middleware
B B
B
Staré rozhraní pro A
log
*
Podmínky spolupráce v alianci Partner se musí nejd íve vyhledat • Partne i musí být dostupní p es ve ejný celosv tový middleware • Rozhraní služeb musí být založeno na obecných standardech • Jazyk zpráv standardizován, v jistém smyslu univerzální • P ístup p es standardní nástroje (prohlíže e) • Poskytované služby popsány standardním zp sobem, popis dostupný (WSDL) • Výhodný je telefonní seznam (UDDI), ale to je centrální služba a mohou s tím být potíže v p2p prost edí, to se již potvrzuje (údržba seznamu)
Komunikace formou zpráv
• žádná data v middlewaru, na internetu se datové úložišt obtížn
implementuje, používá se bezstavová komunikace!! • Pokusy to zm nit - sessiony /
Efektivnost použití
• Efektivnost a použitelnost Jazyk deklarativní Jazyk nízké úrovn
Rozsah použitelnosti
2
Formáty zpráv v alianci • Univerzální ešení: univerzalita procedurálnost SOAP • Programátorsky orientováno
nízká úrove
omezení role uživatel p i definování a ízení business proces a zásazích do jejich chodu, není výhodné pro uživatelsky orientovaná rozhraní, ta jsou ale nutná pro on-line modifikace obchodních proces • Implikuje tvar specifikace služeb (WSDL) a telefonního seznamu (UDDI) • Vhodn jší pro operativu a obecn pro rozhraní bez vlastní inteligence
H
Výhody a nevýhody aliancí Výhody • V e-komerci v podstat jinak nelze • Služby lze programovat autonomn , podobn jako kdysi programy používající hloupé terminály • Využívají se webovské služby a výsledky výzkumu sémantického webu • V lidské spole nosti fungují služby podobn , lze použít analogické postupy
G
Výhody a nevýhody aliancí Nevýhody • Služby nemají uživatelsky orientované rozhraní – obtíže p i použití i p i vývoji (specifikace) • Potíže p i ešení spor , odpov dností a p i ad hoc zásazích do proces (ne ekané události, nové informace), zprávám koncoví uživatelé a experti nerozumí (jak potom vymoci odpov dnost) • Zm ny obchodních proces je nutné ešit uvnit služeb • Neflexibilní, u služeb s vlastnostmi erných sk ín k tém
nereálné
• Existence centrálních služeb je proti duchu p2p • Rozhraní je pracné, má tendenci zviditel ovat implementa ní detaily • Pot ebné normy se rychle m ní a rychle rostou => nestabilita rozhraní
Kdy konfederace • Chceme-li použít uživatelsky orientované nebo existující rozhraní a middleware jiný než webovský • Propojování systém r zných zdroj , • Existující aplikace, vlastní vývoj,produkt t etí strany • r zných vlastník • Organiza ní subsystémy decentralizace • Spolupráce samostatných podnik • a r zných technologií a úkol • P íliš velký systém na monolitické ešení • Inteligentní rozhraní, dávkové techniky • SW inženýrské p ednosti • inkrementálnost, stabilita, láce, …
Souhrn hlavních rys konfederace • Sí autonomních komponent, které mají rysy nebo p ímo jsou aplikacemi • P i navazování komunikace se partner nemusí zpravidla vyhledávat (je znám p edem) • Komponenty jsou používány jako erné sk í ky • • • •
Komplexní funkcionalita, komplexní rozhraní R zné technologie, r zní výrobci Na r zných místech Peer to peer
• Výkonný middleware s podporou flexibilního uživatelského rozhraní a s dalšími funkcemi o které se m že d lit s komponentami (kryptografie, sm rování, optimalizace polohy komponent,…)
Vlastnosti konfederací + Lze dohodnout pravidla šitá na míru formát zpráv m že být deklarativní, uživatelsky orientovaný – klí ová p ednost, snazší specifikace a snazší integrace uživatel do proces lze použít i jiný než webovský middleware, lze kombinovat r zné technologie middlewaru i komunikace služby mohou zahrnovat i služby reálného sv ta ( ízení proces , uživatele), ?doba odezvy?, na webu složit jší lze snadno kombinovat dávkové a interaktivní zpracování lze kombinovat funkcionální a objektové techniky snadná integrace produkt t etích stran a existujících aplikací snadné modifikace a výhodné SW inženýrské vlastnosti k dokumentaci asto sta í popis rozhraní služeb výhodné pro agilní formy vývoje
J
Vlastnosti konfederací II ++ Služby mohou být i informa ní systémy jednotlivých organizací a organiza ních jednotek nebo nakupované/vyvíjené aplikace a dokonce p ímo technologie i jednotliví pracovníci (za vhodným rozhraním), výhody
+ snazší decentralizace, prodej/akvizice ástí podniku + nástroje kontroly spolupráce ástí + snazší spolupráce s obchodními partnery (CRM, SCM, nákupní koalice..) a se státní správou + podpora strategických zám r managementu
Implementace podnikových systém ve form aliance je riskantní, neefektivní a pracná (proto rad ji nap . enterprise service bus) #
Vlastnosti konfederací III - Neví se, je-li v bec možná model driven architecture, platí z ásti i pro aliance, - Chybí dostatek p íklad ešení a CASE nástroje - Problémy s proprietálními ešeními takže nelze vždy použít standardy • lze zmírnit správnou strategií (XML) • m že urychlit vznik uživatelských XML jazyk a tím nevýhodu zm nit na výhodu
+- Nutná úzká spolupráce mezi skoro všemi vývojá i a
mnoha uživateli i z nejvyšších post (CEO se musí ú astnit specifikací) ++ Velmi dobré zkušenosti s provozem (dvacet let bez údržby, viz též zkušenosti s Y2K) *
Konfederace s p e azenými branami • Jak zm nit programátorsky orientované rozhraní na uživatelsky orientované rozhraní A
UR
B PB
A
PB
Middleware
B
PB
A
PB
B
PB
A1
B
Staré rozhraní pro A1
log
UR
P ed azená brána, m že jich být více, mohou i chyb t /
N2 formát a service bus Komunikace služeb m že obecn vyžadovat N*(N-1)/2 formát zpráv. ešením m že být jediný formát pro zprávy mezi všemi p ed azenými branami. To je základní idea ešení Enterprise Service Bus od Sonic Software. Na rozdíl od aliancí si partne i p i spolupráci formáty zpráv nedomlouvají Zprávy mohou být p enášeny mnoha zp soby (signály, mail, telefon, www, …) 2
-
' D
3P
= '
$ 1 ?&
D
HH
“Do roku 2005 bude Podnikovou sb rnici služeb (ESB) kombinující messaging, webové nebo i jiné služby, inteligentní sm rování a transformaci dat, modelování a ízení business proces , používat v tšina podnik .“ Roy Schulte, VP and Research Fellow, Gartner Inc.
Vlastní Vlastní aplikace aplikace JMS JMS
Budoucí Budoucí aplikace aplikace
ERP ERP
Adapter Adapter
Sonic Enterprise Service Bus (ESB) JCA JCA
SOAP/HTTP SOAP/HTTP
Legacy Legacy systems systems
.NET .NET Application Application
XML/HTTP-D XML/HTTP-D Definice sm rovací služby
Internet
Definice transforma ní služby
SOAP/HTTP SOAP/HTTP
Web Web service service
JH
Stumpf Jind ich, Progress Software, SI 2004, p íklad konkrétního projektu Vnit ní integrace
IBIS IBIS Lipt. Lipt. Mikuláš Mikuláš
IBIS IBIS Ružomberok Ružomberok
IBIS IBIS Bratislava Bratislava
Ostatní Ostatní aplikace aplikace
JMS JMS Service Service cont. cont.
JMS JMS Service Service cont. cont.
JMS JMS Service Service cont. cont.
XML/HTTPS XML/HTTPS
Sonic ESB™ File File Adapter Adapter Service Service cont. cont.
Obchodní Obchodní partner partner
Podniková Podniková sb sb rnice rnice služeb služeb E-mail E-mail
Obchodní Obchodní partner partner
Pravidla Pravidla pro pro vým vým nu nu obchodních obchodních dokument dokument
SOAP/HTTPS SOAP/HTTPS
XML/HTTPS XML/HTTPS
Obchodní Obchodní partner partner
Obchodní Obchodní partner partner
JG B2B integrace
Co to p ineslo • Skute n se nemuselo do existujících aplikací sahat • Bylo to velmi rychle hotovo • Plná spokojenost uživatele • Dodavatel ale vlastn realizoval dodávky spíše menší velikosti. D íve by taková dodávka byla podstatn v tší • Bylo mén práce i pro vývojá e (pro ty dramaticky) J
Business procesy •
Mají stav (vlastní data). Jejich pr b h musí být m nitelný i „za b hu“ • Nereálné provád t uvnit aplikací, které jsou dávno odlad né a používané jako erné sk í ky
•
Je nevhodné ídit proces v rámci centralizované služby (d sledek p2p architektury)
•
ešení:Specializovaná služba manažer pro každý proces, simuluje prvky portálu, iniciální data z repozitá e
Portál
Vlastník procesu
Inicializace
Repozitá
Manažer Iniciální data
ízení
Aplika ní služby
Manažer se vytvá í pro každý proces znovu, je to služba která se chová jako instance procesu J
Business procesy Portál
Majitel procesu
Inicializace
Repozitá
Manažer Iniciální data
Aplika ní služby
ešení m že využívat standardy popsané v www.bpmi.org • Modely proces v BPML (dialekt XML) • Data manažeru v BPEL (XML), upravují se podle parametr inicializace zadané vlastníkem procesu Manažer odpovídá instanci procesu podle BPMI. BPMI ale neuvažuje o implementaci jako o služb J
Business procesy ešení s využitím standard popsaných v www.bpmi.org není jediné možné. Další varianty: • Popisy pracovních tok (workflow) • Použití activity diagrams z UML • Jednoduchý fulltextový popis se zaznamenáváním provedených akcí/krok ! asto je nutné používat všechny ty i varianty varianty!!!! • Otížn se implementuje v centrální databázi (obecný problém centrálních DB v p2p systémech)
JJ
9 = 8
1
4
= :
? '1& &
4
9 8 8 > '- &
4 @ & = & 8 :0 4
:
=
? 8 & $ 8'
: A ;< A :
- '( > > $= !8 -E = ?
( &: & 9 : 3 &$AA = : = D 1
&
= A: 9
J#
:= E
1
A 1
Specifikace požadavk • Volba SOA m že ovlivnit i vize (co je reáln možné požadovat), takže rozhodnutí použít SOA musí být u in no v tšinou velmi asn • Specifikace požadavk je pro SOA odlišná od klasických metod, neexistuje vhodné CASE, MDA nelze použít, snad jen zatím • Volba SOA musí být rozhodnutím i CEO i CIO uživatele, ti musí opustit své p edsudky (vše naráz, vše od jednoho výrobce, najít cesty jako využít SOA) • Mnohé se musí nau it i vývojá i
J*
Objektovost a konfederace • Deklarativní rozhraní v XML je výhodn koncipovat neproceduráln • Není tedy voláním metod • Je spíše typu peer to peer • Stavební prvky jsou velké a uzav ené
• Používané technologie a praxe ukazuje, že i p ístup k v ci je v SO odlišný od objektové metodologie J/
Kdy je pot eba objektovost • Od jisté úrovn hierarchie níže již nemohou mít komponenty konfederativní strukturu a nemohou být používány jako erné sk í ky musí být spolehlivé m ly by být OO • P . Ve velmi dob e navržené a implementované konfederaci z USA nebyly kurzovní operace staženy do jednoho objektu. Výsledek – nedalo se to použít
J2
Úvahy a otev ené problémy • Není inženýrsky zvládnuto • Chybí zkušenost (success/failure stories) Chybí metriky, je asi nutné izp sobit metodiku CMM Chybí osv d ené SW procesy pro SOA Problémy s profesní skladbou tým (mén klasických programátor ) Nevíme, co je obtížné a co optimální • Co vše má d lat middleware (kódování) • Jak na mobilní klienty a klonování služeb #H
Úvahy a otev ené problémy • Nevíme jak optimáln využívat zna kovací jazyky, p edevším jejich metaúrove • Obchodní politika uživatel a výrobc • Souvislost s autonomními agenty a metapo ítáním • Optimalizace výkonu konfederace (mobilita, klonování) • Kdy je konfederace výhodná a kdy ne #G
Úvahy a otev ené problémy • Jak upravit studium a školení po íta ových expert • Nutnost výuky ekonomie, induktivního
uvažování a n kterých humanitních obor . To je obecný problém inženýrského studia, pro SW zvlášt urgentní • Nutnost otev enosti a adaptibility • Syndrom o všem n co nic po ádn • Syndrom hackera. S lidmi nerad jednám #
Co chybí • Obecná shoda o typech SOSS • Pov domí, jako optimáln kombinovat OO a SO, • P íklady ešení (case studies, best practices) • D lba práce mezi middleware, centrální služby, infrastrukturní služby a aplika ní služby • Vhodné modelovací nástroje (model driven architecture) a CASE systémy #
Co lze o ekávat v budoucnosti Zlepšení HW podpory Dostupnost a kapacita linek Poslední míle (WiMax, WiFi, Mobily, telefony)
Komer ní nástroje .NET?, Service Bus, Net Weaver, nové CASE
Vy ešení v cných problém Hranice služeb, uživatelsky orientované standardy, komer ní ešení, zvládnutí paradigmatu, best practices, Petriho sít
#
Co lze ekat v budoucnosti Obchodn manažerské problémy Obchodní praktiky výrobc i odb ratel , zm ny SW proces , zm ny organizace uživatel
Subjektivní omezení Zm na postoj , p ijetí paradigmatu, specifikace požadavk ve spolupráci „všech“, zm ny ve výchov informatik
Vedle podpory obchodních proces pr nik SOA do sv ta zábavy což vynese gigadolary #J
D sledky pro SW profese • Nejasný vliv na pot ebu psaní nových komponent od za átku • Lze snáze uplatnit v existujícím balíku a snáze doplnit
funkce do svého produktu • Komponentu lze získat kdekoliv na sv t
• V tší d raz na nepo íta ové znalosti a otev enost myšlení • Nutnost rozum t funkcím komponent, tedy jiným obor m
(nap . statistika) • Pot eba um t doporu it správné komponenty
• Um t vid t a analyzovat souvislosti (výhodné i pro p ípadnou zm nu profese) ##
O SOA je v praxi realita, slibuje snazší spln ní požadavk zákazník . SOA slibuje SW jako standardní pr myslový výrobek to asi p isp je k dalšímu r stu významu informatiky. Zatím asto drženo pod pokli kou, situace se ale m ní (viz, Sonic ESB nebo NetWeaver od SAP). Velká výzva pro odborný profil informatik (roste d ležitost managementu a znalostí mimo informatiku). P íležitosti: Obtížn se outsourcuje do Indie, závisí na kulturním prost edí nebo je nutná v tší spolupráce s uživateli, nové možnosti tvorby služeb. I hrozby pro informatiky (znovupoužitelnost). Celkov spíše p íznivé, chce ale zm nu znalostí a zvyk (VÝZVA) #*
