S. Adam: Už před rokem jsme se rozhodli předělat nás základní systém a volba padla na webové služby. Jde hlavně o to, že systém musí být otevřený i pro naše dealery a k tomu jsou WS ideální platformou. Využíváme embedded ESB (webMethods), což je sice drahé řešení, ale spolehlivé a univerzální. Projekt má řídící výbor na vrcholové úrovni a jsou do něj zapojeni i specialisté na procesy.
Sadil: Technologii ESB máme k dispozici v rámci platformy, ale zatím váháme. Některá propojení sice řešíme přes SOAP, ale jednotným konceptem SOA bych to nenazval. Řídíme to sami v IT Dep.
Jiřina: Velký projekt na systém založený na WS jsme absolvovali už loni. Běžel jako všechny IT projekty - byli do něj zapojeni pouze vybraní dotčení uživatelé, jinak si ho řídl náš CIO.
Komárek: U našich informatiků je SOA zakázané slovo. Prá vede jen k chaosu a nerušení bezpečnosti. Mimo IT o SOA nikdo nic netuší, takže nějaká představa, že by právě SOA pomohla spojit aktivity shora od vedení a od IT není u nás moc reálná.
Mareš: Přímo SOA iniciativa to není, ale na SOA technologiích je postavena - máme velký projekt BI, který využívá ESB pro přístup k některým službám back-systémů. Projekt je řízen IT.
Králová: Se SOA mi už tak rok dávají naši informatci SODu. Po pravdě nechápu ještě pořád úplně přesně, kam to celé míří a proč najednou se musí všechna rozhraní dělat přes XI (v SAPu), když to nikdo pořádně neumí a je to nespolehlivé. Což s celkovou architekturou SOA nemá moc společného a ani to k ní nemíří. Nemám pravdu?
V.L.: Máte pravdu, že SAPovský NetWeaver není zrovna příkladná platforma k rozklíčování stávajících aplikací do služeb.
Karel Svoboda: Otázka asi míří k tomu, zda už někdo nemá zkušenost s projekty SOA napojenými na business aktivity shora. Bohužel musím konstatovat, že u nás běží obojí dvěma odlišnými linkami. Business projekty sice nakonec u IT taky skončí, ale až je jasné, co se má změnit. IT si dělá nezávisle své projekty. SOA se u nás moc neskloňuje, ale na webslužbách už máme založenu řadu řešení.
pass: O SOA umí naší IT mistři mluvit velmi vznešeně. Právě teď máme na stole projekt na předělání nějakých n:m rozhraní. Projekt je navržen jako čistě informatický a jediné, čím je zdůvodněn, že při nových verzích oněch molochů se nebudou muset rozhraní pořád znovu předělávat.
Levadule: Už půl roku děláme velký integrační projekt, kdy se má využít k vzájemnému propojení systémů výhradně SOAP. Byznysu se to "netýká" - takže se o to nikdo z managementu nestará.
Z diskuse Spolupracují na projektech SOA lidé z BPM?
Jak na BPM a SOA prakticky
V konceptu BPM druhé generace jsou služby základním stavebním kamenem pro procesy podnikání. Služby mohou být používány opakovaně v jiném byznys kontextu a mohou být navzájem kombinovány. Přitom snadný vývoj a zjednodušené nasazování zejména webových služeb na bázi otevřených standardů umožňuje rychle doplnit chybějící funkcionality.
Servisně orientovaná architektura (SOA) tedy umožňuje sestavit z dostupných služeb optimální proces. Tím celému BPM poskytuje potřebnou infrastrukturu pro flexibilní design procesů při maximálním znovupoužití již existujících služeb.
Standardy
Základem otevřenosti servisně orientované architektury jsou standardy a těch začíná být nepočítaně:
Ty nejdůležitější z hlediska vztahu SOA a BPM jsou:
- BPMN - notace pro popis byznys procesů, která nemusí být až ta úplně nepostradatelná, jak probereme níže
- BPEL - jazyk orchestrace procesů, který je podepřen celou řadou standardů, např. WS-BPEL (automatizované workflow) či BPEL4People (interaktivní workflow)
- WSDL - standardní popis rozhraní služeb, které umožňuje, aby tuto službu využíval jakýkoliv klient, který je rozšířen o řadu praktických specifikací umožňujících využití služeb v reálné praxi, např. WS-ReliableMessaging, WS-Addressing, WS-Notification, WS-Security atd.
Postup při návrhu procesu
1. Byznys modelování
Vlastní modelování podnikového prostředí se prakticky neliší od běžného modelování podniku. Business model společnosti (BMS) by měl zachytit všechny podstatné aspekty podnikové architektury a jejich vztahy. Minimálně to je:
- organizační dimenze - organizační struktury, jejich kompetence ve vazbě na procesy a potřebné znalosti
- dimenze výkonnosti a řízení změn - strategie a její vazba na procesy a zdroje, výkony a jejich měření včetně ukazatelů výkonnosti
- dimenze zdrojů - z hlediska IT podniková architektura (EAI)
- procesní dimenze - celkový přehled procesů na potřebných úrovních podrobnosti až po tok přidané hodnoty v jednotlivých end-to-end procesech
Standardní notací pro modelování procesního toku je BPMN, která však má řadu omezení a nevýhod. Nic však nebrání využít pro záznam podrobného toku činností notaci EPC.
Na úrovni byznys modelů as-is je možno provádět analýzy včetně dynamických (simulace) a navrhovat optimalizace, které se zachytí do modelů to-be určených k implementaci.
2. Orchestrace
Byznys modely v notaci BPMN nebo EPC je nutné překlopit do jazyku BPEL. Většina modelovacích nástrojů umožňuje provést tuto konverzi automaticky a mít tyto modely umístěné v jednotné repository BMS. Jenže tím práce teprve začíná.
Do této repository je nutné nahrát standardní popis služeb ve formátu WSDL. Popis procesů v BPEL je nutné většinou dále zjemnit tak, aby bylo možné připojovat jednotlivé služby. A následně pro jednotlivé aktivity v BPEL příslušné služby připojit a nastavit jejich chování.
Uveďme ještě příklad tohoto postupu z hlediska možné kombinace použití nástrojů z různých rodin:
- Byznys modelování provedeme například v některém z nástrojů rodiny ARIS. Podrobný popis procesů máme zachycen v notaci EPC.
- EPC modely automaticky konvertujeme do notace BPEL a verifikujeme je zejména z hlediska jednoznačnosti. K tomu potřebujeme již specializovaný nástroj ARIS Business Architect. Výhodou je, že i BPEL notace má srozumitelnou vizualizaci.
- Následně exportujeme tyto modely pomocí rozhraní ARIS2WebSphere a naimportujeme je do repository WebSphere.
- K orchestraci služeb využijeme nástroj WebSphere Integration Developer. Do jeho repository naimportujeme popis služeb (WSDL) a objektů (XSD) a uspořádáme je.
- Podle potřeby zpřesníme popis v BPEL, připojíme jednotlivé služby, nastavíme jejich parametry a napojíme rozhodování na příslušná pravidla. Vytvoříme obrazovky pro lidské aktivity.
- Výsledný proces otestujeme a můžeme používat v prostředí WebSphere Process Server. Ten podporuje běh jak automatizovaných procesů, tak procesů s lidskou interakcí včetně interpretace pravidel.
3. Vývoj
Pokud ve fázi byznys modelování či nejpozději orchestrace zjistíme, že některá část procesu potřebuje jinou nebo novou službu, navrhneme její funkcionalitu (např. v nástroji ARIS UML Designer). K tomuto účelu se nejvíce využívá notace UML.
Následně je v příslušném vývojovém nástroji (např. Rational Software Architect) navržena a vyvinuta potřebná SW komponeta a následně je tato komponenta zpřístupněna jako služba (např. pomocí Rational Application Developer).
Podívejme se ještě jednou na celé schéma propojení BPM a SOA (zdroj ON-Demand Business):
4. Monitoring
Jedním z přínosů konceptů SOA pro BPM je dostupnost dat o chování procesů v reálném čase. Monitoring průběhu procesů většinou zajišťuje nějaký specializovaný nástroj nad respository procesního serveru (např. WebSphere Business Monitor) a ten umožňuje nejen sledovat průběhy procesů a jejich parametry (např. pomocí definovaných KPI's), ale i export těchto dat zpět do modelovacího nástroje k analýzám a simulaci.
O čem byla diskuse
Do diskuse byla položena pouze jediná otázka - Kdo řídí iniciativy SOA a zda jsou do nich nějak zapojeni lidé odpovědní ve firmách za BPM. Podle uvedených názorů běží v podnicích řada projektů charakteru SOA zaměřených na implementaci ESB jako prostředku pro zpřístupnění stávajících aplikací a systémovou integraci či vývojových projektů na bázi webových služeb.
Všechny tyto projekty řídí výhradně IT jako klasické informatické projekty. V diskusi nezazněla jediná zkušenost, která by naznačila jiný způsob zapojení byznys analytiků do těchto projektů resp. převedení těchto projektů do společného rámce BPM & SOA.
A tak se zdá, že tento plně technicky dostupný a účinný přístup ještě čeká na svou příležitost. Tu mu vytvoří jen jiná firemní kultura, která přestane separovat byznys a IT a vrátí se zpátky k jejich spolupráci.
Více.....
BPM a SOA - úvod do tématu
BPM a SOA jsou jako čokoláda a arašídové máslo. Jednotlivě dobré, dohromady báječné. (Michael Stamback) Není tedy pravda, že se bez sebe vzájemně neobejdou, ale že společně mohou vytvořit zcela novou kvalitu řešení. Proč? V čem? Za jakých podmínek? Na tyto otázky hledáme odpovědi v tématu měsíce.
Základní pojmy v oblasti SOA
SOA - servisně orientovaná architektura. Pojem SOA může znamenat paradigma, koncept, architekturu, metodologii či technické řešení softwarové struktury a aplikací. Nebo všechno současně - vždy záleží na kontextu, ve kterém je použit.
Klíčovým pojmem je služba (servis) - ta reprezentuje vysokoúrovňové rozhraní do aplikační logiky. Toto rozhraní se chová jako koncový bod, který reaguje na asynchronní události (zprávy). Softwarový fragment, který poskytuje službu, nazýváme komponentou. Může jít jak o webovou službu (WS), tak o službu vytvořenou pomocí podnikové sběrnice služeb (ESB) prakticky z libovolné zdrojové aplikace jejím zapouzdřením do kontejneru. Služby jsou katalogizovány v centralizované repository, využívané i pro vynucování potřebných politik - pravidel z hlediska bezpečnosti, dostupnosti, správy životního cyklu služeb atd.
Přínosy SOA
Jaké poskytuje SOA zásadní přínosy pro BPM? Především se celá oblast IS zdrojů stává pro BPM čitelnou. Modularizované funkcionality IS je možné namapovat na konkrétní činnosti, které jsou jimi podporovány. Jsou předem známy potenciály, ale i omezení stávajících služeb a je jednodušší zadat jejich vývoj. Celý cyklus změny probíhá v jednotném prostředí a je tak podstatně více pod kontrolou z hlediska splnění cílů.
SOA je výsledkem praktické evoluce a nahrazuje někdy až příliš dokonalé a složité standardy (RPC, COM/DCOM, CORBA, RMI, EJB...) usilující o integraci. Pro podnikové využití se navíc otvírá stále rostoucí množství externích služeb, které je možné kombinovat a vytvářet tak velmi rychle míchanice (mashup) s potřebnou funkcionalitou.
Příspěvky
