This is an old revision of the document!
Table of Contents
23. Aplikační integrace
Aplikační integrace, vazba na podnikatelské procesy, podnikatelské přínosy, přístupy a prostředky pro vnitro-podnikovou a mezi-podnikovou integraci, zhodnocení, vývoj v dané oblasti.
Úloha
Předpoklady: Máte ve vaši firmě za úkol navrhnout způsob integrace s vaším velkým dodavatelem.
Zadání: jaké informace pro tuto volbu potřebujete, kde je získáte, jaké alternativy budete uvažovat, jak se rozhodnete.
Teorie
Enterprise_application_integration
http://findarticles.com/p/articles/mi_qa3937/is_200203/ai_n9019202
http://www.systemonline.cz/clanky/bpi-integrace-podnikovych-procesu.htm
http://www.enterpriseintegrationpatterns.com/toc.html
Popis problému
- Takže máme nějaké podnikové aplikace (tj. složité, podporující životně důležité funkce podniku) a chceme je integrovat neboli propojit tak, aby komunikovaly mezi sebou a s uživateli a s partnery atd.
- Naši klienti považují naší firmu za jednolitý podnik a očekávají, že s námi bude rozumná komunikace jako člověk s člověkem, nikoli jako člověk s miliónem nepropojených aplikací (podnikové procesy jdou napříč odděleními, skrze všemožné aplikace).
- Nejsou na to standardy, je to komplexní problematika, zasahuje mnoho úrovní abstrakce, různé druhy aplikací, různé systémy, nad kterými třeba ani nemáme úplnou kontrolu
- Mezi celkovou vizí integrace aplikací a samotnou implementací je velká díra, kde chybí metodiky, standardy, návrhové vzory atd.
- Většina literatury je vágní, nebo se věnuje určitému výrobci a konkrétní technologii (a la MS BizTalk atd.)
- Hodně se mluví o standardech, ale nejsou best practices
- A architektů, který rozumí integraci aplikací je jako šafránu
Způsoby integrace
70. léta - Dávková výměna dat
- vyexportovat, třeba do COBOLem čitelných souborů
- načíst do cílového systému
- výhody: dobrá fyzická nezávislost, nezávislost na jazyku a systému
- nevýhody: není to okamžitý přenos dat, systémy nejsou synchronizované, obrovské množství dat
80. léta: Centrání Databáze
- Všechny aplikace sdílí jednu velkou databázi
- výhody: konzistence dat, tvorba reportů
- nevýhody: integrace dat, ne business funkcí, problém společné reprezentace dat pro všechny aplikace
90. léta: RPC (Remote Procedure Calls)
- jedná aplikace vzdáleně volá přímo funkci jiné aplikaci
- potřebná data jsou přenesena v rámci dotazu a výsledek je zabalen do odpovědi
- výhody: výměna dat on-demand, integruje i business funkce, nejen data
- nevýhody: funguje dobře s malým počtem systémů, křehká stavba (pevná vazba), výkon?
Dnes: Messaging
- posílání zpráv na sběrnici, nebo do fronty
- k odebírání zpráv se může zaregistrovat více subjektů
- messaging nabízí hodně dodavatelů “EAI” - IBM WebSphere MQ, TIBCO, WebMethods, Java Messaging (JMS), Microsoft .NET System.Messaging, Asynchronous Web Services
- výhody: přenos dat on-demand, integrace business funkcí, volné vazby, asynchronní provoz
- nevýhody: zatím ne tak obvyklý postup, obtížnější testování, někdy je potřeba i synchronní odpověď
Messaging
Messaging se stará o několik úloh. Následuje výběr návrhových vzorů podle knihy Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions od Gregor Hohpe a Bobby Woolf (online verze). Nejedná se o žádnou metodiku, standard, kompletní řešení ani jazyk, jde jen o vzory, kterými disponují různá konkrétní řešení, často proprietální a s různým slangem (každý tomu říká jinak, dává tomu hogo-fogo marketingový název, ale v zásad je to totéž).
- Transport zpráv ⇒ Channel Patterns
- Message Channel - asynchronní spolehlivý přenosový kanál, který drží zprávy dokud není příjemce k dispozici
- Point-to-Point Channel - přímý kanál jeden odesílatel - jeden příjemce
- Publish-Subscribe Channel - jeden odesílatel, libovolný počet příjemců zprávy (zaregistrují se), multicast
- Design zpráv ⇒ Message Patterns
- Return Address - obsahem zprávy zpáteční adresa, kam má být zaslána odpověď
- Correlation Identifier - obsahem zprávy je unikátní identifikátor, aby bylo možné spárovat zprávu s odpovědí
- Směrování zpráv k cíli ⇒ Routing Patterns
- Message Router - komponenta směrující zprávy k různým cílům (na základ náhody, obsahu, času, záteže atd.)
- Recipient list - přesně určený seznam příjemců, kterým se řídí message router
- Splitter - rozděluje zprávy na části, každou směruje jinam jako samostatnou zprávu
- Aggregator - spojuje více zpráv do jedné
- Auction - jedna zpráva je odeslána více příjemcům (PubSub, nebo Recipients), jejich odpovědi jsou spojeny do jedné odpovědi (Aggregatorem)
- Transformace zpráv do různých formátů ⇒ Transformation Patterns
- Data Enricher - obohacení zprávy o další části/informace, které odesílatel nemá k dispozici
- Content Filter - vyfiltrování zajímavé části zprávy, odstranění nepodstatných/nevhodných částí zprávy
- Check Baggage - odložení části obsáhlé zprávy stranou, po zpracování opět obohacena u původní data (aby se ušetřila zátěž)
- Produkování a konzumace zpráv ⇒ Endpoint Patterns
- Messaging Gateway - prostředník pro napojení aplikace na messaging
- Polling Consumer - klient messagingu, který pravidelně jednou za čas vyzvedne zprávy
- Event-driven Consumer - klient řízený událostmi
- Řízení a testování messaging systému ⇒ Management Patterns
- Message store - úložiště prošlých zpráv, např. pro potřeby pozdější analýzy, reportingu
- Test message - testovací zpráva, vpravená do ostré komunikace v určitém místě a opět odchycená na jiném - umožňuje testovat vybrané části systému, identifikovat chyby
Praxe




