Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00629 008444 13445712 na godz. na dobę w sumie
ESB. Magistrala usług korporacyjnych - ebook/pdf
ESB. Magistrala usług korporacyjnych - ebook/pdf
Autor: Liczba stron: 272
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-9173-9 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> sieci komputerowe >> inne
Porównaj ceny (książka, ebook (-20%), audiobook).

Integracja systemów dla praktyków!

Integracja systemów oraz zapewnienie komunikacji między różnymi ich komponentami to ogromne wyzwanie. Podczas tworzenia własnych rozwiązań prawdopodobnie natkniesz się na dziesiątki problemów. Dlatego warto rozważyć możliwość wykorzystania sprawdzonych narzędzi. Należy do nich magistrala ESB (skrót od ang. Enterprise Service Bus). Magistrala taka zapewnia inteligentne zarządzanie ruchem, transformację danych, przesyłanie komunikatów i nie tylko. Brzmi obiecująco? Przekonaj się sam!

Sięgnij po tę książkę i poznaj interesujące strategie wykorzystania ESB. Na początku znajdziesz podstawy — właściwości magistrali, jej historię oraz formaty wymiany komunikatów. Z kolejnych rozdziałów dowiesz się, jak skutecznie integrować usługi, wywoływać komunikaty oraz korzystać z niestandardowych adapterów. Ponadto skupisz się na aspektach związanych z bezpieczeństwem magistrali oraz jej konfiguracją. Nauczysz się również radzić sobie w przypadku wystąpienia problemów z przepustowością magistrali oraz opóźnieniami transferu. Książka ta jest unikalną pozycją, poświęconą interesującym zagadnieniom związanym z magistralą ESB. Jest to Twoja lektura obowiązkowa!

Dzięki tej książce:

Poznaj zaawansowane techniki integracji systemów!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Enterprise Service Bus: Theory in Practice Tłumaczenie: Piotr Pilch ISBN: 978-83-246-9170-8 © 2014 Helion S.A. Authorized Polish translation of the English edition of Enterprise Service Bus, ISBN 9780596006754 © 2004 David A. Chappell This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls rights to publish and sell the same. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie bierze jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Wydawnictwo HELION nie ponosi również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Projekt okładki: Studio Gravite/Olsztyn Obarek, Pokoński, Pazdrijowski, Zaprucki Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock Images LLC. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/intsys Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis tre(cid:316)ci Przedmowa ....................................................................................................................7 Wst(cid:253)p .............................................................................................................................9 9 O ksi(cid:241)(cid:276)ce 10 Przegl(cid:241)d rozdzia(cid:228)ów Konwencje dotycz(cid:241)ce wzorców integracji magistrali ESB 13 19 Konwencje u(cid:276)ywane w ksi(cid:241)(cid:276)ce Podzi(cid:246)kowania 19 1. Magistrala ESB — wprowadzenie .............................................................................. 21 22 22 23 24 25 26 28 39 42 Architektura SOA w przedsi(cid:246)biorstwie sterowanym zdarzeniami Nowe podej(cid:264)cie do uniwersalnej integracji Architektura SOA dla us(cid:228)ug WWW Tradycyjne metody integracji Wymagania okre(cid:264)lane potrzebami dzia(cid:228)u informatycznego Zainteresowanie ze strony bran(cid:276)y W(cid:228)a(cid:264)ciwo(cid:264)ci magistrali ESB Zaadaptowanie magistrali ESB w bran(cid:276)ach Podsumowanie 2. Stan integracji ..............................................................................................................43 44 49 56 58 63 Biznesowe czynniki nap(cid:246)dowe wymuszaj(cid:241)ce integracj(cid:246) Stan integracji w przedsi(cid:246)biorstwach Wykorzystanie sprawdzonych procedur z technologii EAI i SOA Refaktoryzacja do magistrali ESB Podsumowanie 3 Kup książkęPoleć książkę 3. Potrzeba jest matk(cid:233) wynalazku .................................................................................65 67 68 71 75 78 81 Rozwój magistrali ESB Magistrala ESB w produkcji globalnej Znajdowanie granicy rozbudowanego przedsi(cid:246)biorstwa Integracja oparta na standardach Analiza przypadku: produkcja Podsumowanie 4. Format XML: fundament integracji danych biznesowych .........................................83 83 85 90 93 98 J(cid:246)zyk integracji Aplikacje „wyginaj(cid:241) si(cid:246)”, lecz nie „p(cid:246)kaj(cid:241)” Routing oparty na tre(cid:264)ci oraz transformacja Ogólna architektura wymiany danych Podsumowanie 5. Oprogramowanie MOM ..............................................................................................99 100 106 110 112 115 118 120 121 Porównanie interfejsu (cid:264)ci(cid:264)le powi(cid:241)zanego z interfejsem lu(cid:274)no powi(cid:241)zanym Poj(cid:246)cia zwi(cid:241)zane z oprogramowaniem MOM Niezawodno(cid:264)(cid:232) asynchroniczno(cid:264)ci Niezawodne modele przesy(cid:228)ania komunikatów Komunikaty transakcyjne Wzorzec przesy(cid:228)ania komunikatów typu (cid:276)(cid:241)danie/odpowied(cid:274) Standardy przesy(cid:228)ania komunikatów Podsumowanie 6. Kontenery us(cid:293)ug i abstrakcyjne punkty ko(cid:295)cowe .................................................... 123 124 126 126 128 131 132 139 146 Architektura SOA zapewniana przez abstrakcyjne punkty ko(cid:254)cowe Przesy(cid:228)anie komunikatów i (cid:228)(cid:241)czno(cid:264)(cid:232) w rdzeniu Ró(cid:276)ne opcje po(cid:228)(cid:241)cze(cid:254) Notacje dotycz(cid:241)ce diagramów Niezale(cid:276)ne us(cid:228)ugi integracji mo(cid:276)liwe do wdro(cid:276)enia Kontener us(cid:228)ug magistrali ESB Kontenery us(cid:228)ug, serwery aplikacji i brokery integracji Podsumowanie 7. Wywo(cid:293)ania us(cid:293)ug magistrali ESB, routing i architektura SOA ................................ 147 147 148 148 150 156 157 165 Znajdowanie, wi(cid:241)zanie i wywo(cid:228)ywanie Wywo(cid:228)ywanie us(cid:228)ug magistrali ESB Routing oparty na trasach: architektura SOA o wysokim stopniu rozproszenia Routing oparty na tre(cid:264)ci Wielokrotne wykorzystywanie us(cid:228)ug Specjalizowane us(cid:228)ugi magistrali ESB Podsumowanie 4 (cid:95) Spis tre(cid:316)ci Kup książkęPoleć książkę 8. Protoko(cid:293)y, przesy(cid:293)anie komunikatów, niestandardowe adaptery i us(cid:293)ugi ............ 167 167 172 181 188 Rdze(cid:254) MOM magistrali ESB Ogólna struktura wywo(cid:228)a(cid:254) komunikatów Analiza przypadku: integracja z partnerem Podsumowanie 9. Opó(cid:346)nienie transferu w trybie wsadowym ............................................................. 189 190 194 Wady metody ETL Typowe rozwi(cid:241)zanie: utrzymywanie nadmiernych stanów magazynowych Analiza przypadku: migracja w celu zapewnienia integracji w czasie rzeczywistym Podsumowanie 195 202 10. Komponenty Java w magistrali ESB ..........................................................................205 206 209 211 218 Specyfikacja JBI Architektura JCA Technologia JMX Podsumowanie 11. Wzorce integracji magistrali ESB i powtarzaj(cid:233)ce si(cid:253) rozwi(cid:233)zania projektowe ..... 219 220 223 226 235 239 244 Wzorzec VETO Dwukrokowy wzorzec XRef Wzorce integracji serwera portalu Wzorzec integracji buforowania z przekazywaniem Wzorce zapyta(cid:254) stowarzyszonych Podsumowanie 12. Magistrala ESB i rozwój us(cid:293)ug WWW .......................................................................247 248 248 251 253 Mo(cid:276)liwo(cid:264)(cid:232) wspó(cid:228)dzia(cid:228)ania specyfikacji Podsumowanie specyfikacji WS-* Adaptowanie specyfikacji WS-* w magistrali ESB Podsumowanie Dodatek: lista dostawców magistrali ESB ................................................................255 Bibliografia ................................................................................................................257 Skorowidz .................................................................................................................. 261 Spis tre(cid:316)ci (cid:95) 5 Kup książkęPoleć książkę 6 (cid:95) Spis tre(cid:316)ci Kup książkęPoleć książkę MAGISTRALA ESB — WPROWADZENIE W ka(cid:276)dej bran(cid:276)y osoby zarz(cid:241)dzaj(cid:241)ce firmami wymagaj(cid:241) uzyskania wi(cid:246)kszej warto(cid:264)ci z reali- zowanych przez nie strategicznych procesów biznesowych. Cho(cid:232) to, jaki proces ma strate- giczne znaczenie dla danej firmy, mo(cid:276)e ró(cid:276)ni(cid:232) si(cid:246) znacz(cid:241)co w zale(cid:276)no(cid:264)ci od bran(cid:276)y, wspólne jest, (cid:276)e prezesi oczekuj(cid:241) od swoich dzia(cid:228)ów informatycznych wyra(cid:274)nego usprawnienia prze- p(cid:228)ywu danych oraz informacji, na podstawie których podejmowane s(cid:241) kluczowe decyzje biz- nesowe. Niezale(cid:276)nie od tego, czy jest to firma (cid:264)wiadcz(cid:241)ca us(cid:228)ugi finansowe, która zamierza uzyska(cid:232) przewag(cid:246) nad konkurencj(cid:241), gwarantuj(cid:241)c wi(cid:246)cej szybszych walutowych operacji handlowych, sie(cid:232) sprzeda(cid:276)y detalicznej oczekuj(cid:241)ca przyspieszenia przep(cid:228)ywu danych maga- zynowych z powrotem do mened(cid:276)erów odpowiedzialnych za mark(cid:246) pracuj(cid:241)cych w centra- lach korporacyjnych, czy dostawca materia(cid:228)ów budowlanych domagaj(cid:241)cy si(cid:246) optymalizacji przep(cid:228)ywu zamówie(cid:254) w ramach z(cid:228)o(cid:276)onej sieci dystrybucyjnej, niezb(cid:246)dne jest uporanie si(cid:246) ze wspólnymi znacznymi wyzwaniami natury technicznej. Informacje s(cid:241) zablokowane w apli- kacjach znajduj(cid:241)cych si(cid:246) w ró(cid:276)nych dzia(cid:228)ach i ró(cid:276)nych firmach. Wydobywanie tych danych jest zarówno czasoch(cid:228)onne, jak i kosztowne. Podsumowuj(cid:241)c: przedsi(cid:246)biorstwo jest dalekie od bycia zintegrowanym. W ostatniej dekadzie pojawi(cid:228)o si(cid:246) kilka znacz(cid:241)cych trendów technologicznych, takich jak Se- rvice Oriented Architecture (SOA), Enterprise Application Integration (EAI), Business-to-Business (B2B) oraz us(cid:228)ugi WWW. W ich przypadku próbowano upora(cid:232) si(cid:246) z wyzwaniami maj(cid:241)cymi na celu poprawienie wyników i zwi(cid:246)kszenie warto(cid:264)ci zintegrowanych procesów biznesowych. Technologie wzbudzi(cid:228)y du(cid:276)e zainteresowanie liderów bran(cid:276)y informatycznej, dostawców oraz analityków bran(cid:276)owych. Magistrala us(cid:228)ug korporacyjnych (ESB — Enterprise Service Bus) ofe- ruje najlepsze cechy tych oraz innych trendów technologicznych. Pod poj(cid:246)ciem magistrali ESB kryje si(cid:246) nowa metoda integracji, mog(cid:241)ca zapewni(cid:232) podstawy lu(cid:274)no powi(cid:241)zanej sieci integracji o wysokim stopniu rozproszenia. Umo(cid:276)liwia ona skalowanie przekraczaj(cid:241)ce granice wyznaczone przez broker EAI z konfiguracj(cid:241) gwia(cid:274)dzist(cid:241). Magistrala ESB to oparta na standardach platforma integracji, (cid:228)(cid:241)cz(cid:241)ca w sobie przesy(cid:228)anie komunikatów, us(cid:228)ugi WWW, transformacj(cid:246) danych i inteligentne kierowanie w celu niezawodnego nawi(cid:241)- zywania po(cid:228)(cid:241)cze(cid:254) oraz koordynowania interakcji znacznej liczby ró(cid:276)nych aplikacji mi(cid:246)dzy roz- budowanymi przedsi(cid:246)biorstwami (ang. extended enterprises) z integralno(cid:264)ci(cid:241) transakcyjn(cid:241). 21 Kup książkęPoleć książkę Rozbudowane przedsi(cid:246)biorstwo reprezentuje organizacj(cid:246) i jej partnerów biznesowych, którzy s(cid:241) rozdzieleni zarówno przez granice biznesowe, jak i fizyczne. W przypadku rozbudowanego przedsi(cid:246)biorstwa nawet aplikacje, które s(cid:241) kontrolowane przez jedn(cid:241) korporacj(cid:246), mog(cid:241) by(cid:232) oddzielone od siebie geograficznie, a tak(cid:276)e odseparowane za pomoc(cid:241) korporacyjnych zapór firewall i zasad zabezpiecze(cid:254) obowi(cid:241)zuj(cid:241)cych mi(cid:246)dzy dzia(cid:228)ami. Architektura SOA w przedsi(cid:253)biorstwie sterowanym zdarzeniami W przedsi(cid:246)biorstwie sterowanym zdarzeniami (ang. event-driven enterprise) zdarzenia bizne- sowe wp(cid:228)ywaj(cid:241)ce na normalny przebieg procesu biznesowego mog(cid:241) wyst(cid:246)powa(cid:232) w dowol- nej kolejno(cid:264)ci i w dowolnym momencie. Aplikacje wymieniaj(cid:241)ce dane w zautomatyzowanych procesach biznesowych musz(cid:241) komunikowa(cid:232) si(cid:246) ze sob(cid:241) za pomoc(cid:241) sterowanej zdarzeniami architektury SOA, aby elastycznie reagowa(cid:232) na zmieniaj(cid:241)ce si(cid:246) wymagania biznesowe. Ar- chitektura SOA zapewnia analitykowi biznesowemu lub architektowi integracji obszerny wi- dok abstrakcyjny aplikacji i komponentów integracji, które mog(cid:241) by(cid:232) obs(cid:228)ugiwane jako us(cid:228)u- gi wysokopoziomowe. W przypadku magistrali ESB aplikacje i us(cid:228)ugi sterowane zdarzeniami s(cid:241) ze sob(cid:241) powi(cid:241)zane w ramach architektury SOA w lu(cid:274)ny sposób. Umo(cid:276)liwia im to dzia(cid:228)a- nie niezale(cid:276)nie od siebie przy jednoczesnym oferowaniu korzy(cid:264)ci bardziej ogólnej funkcji biznesowej. W (cid:264)wiecie architektury SOA zdarzenia s(cid:241) reprezentowane w otwartym formacie XML, a ponadto przep(cid:228)ywaj(cid:241) przez transparentny potok, który mo(cid:276)e by(cid:232) sprawdzany i podlega intermediacji. — John Udell, InfoWorld Komponenty us(cid:228)ug w architekturze SOA udost(cid:246)pniaj(cid:241) proste interfejsy, których zadaniem jest asynchroniczne wspó(cid:228)u(cid:276)ytkowanie danych mi(cid:246)dzy aplikacjami. U(cid:276)ywaj(cid:241)c magistrali ESB, ar- chitekt integracji (cid:228)(cid:241)czy ze sob(cid:241) aplikacje i odr(cid:246)bne komponenty integracji w celu utworzenia zespo(cid:228)ów us(cid:228)ug do zdefiniowania z(cid:228)o(cid:276)onych procesów biznesowych, które z kolei automaty- zuj(cid:241) funkcje biznesowe w rzeczywistym przedsi(cid:246)biorstwie. Magistrala ESB zapewnia architekturze SOA szkielet implementacji. Oznacza to, (cid:276)e oferuje lu(cid:274)no powi(cid:241)zan(cid:241) architektur(cid:246) SOA sterowan(cid:241) zdarzeniami ze znacznie rozproszon(cid:241) domen(cid:241) nazwanych miejsc docelowych routingu w ramach magistrali komunikatów obs(cid:228)uguj(cid:241)cej wiele protoko(cid:228)ów. W przypadku magistrali ESB aplikacje (i komponenty integracji) na poziomie abs- trakcji s(cid:241) od siebie oddzielone. (cid:227)(cid:241)czone s(cid:241) za po(cid:264)rednictwem magistrali jako logiczne punkty ko(cid:254)cowe prezentowane jako us(cid:228)ugi sterowane zdarzeniami. Dzi(cid:246)ki swojej rozproszonej infrastrukturze wdra(cid:276)ania magistrala ESB mo(cid:276)e skutecznie za- pewnia(cid:232) scentralizowane konfigurowanie i wdra(cid:276)anie us(cid:228)ug rozproszonych w obr(cid:246)bie roz- budowanego przedsi(cid:246)biorstwa oraz zarz(cid:241)dzanie nimi. Nowe podej(cid:316)cie do uniwersalnej integracji Wspólnym celem stosowania technologii, takich jak SOA, EAI, B2B i us(cid:228)ugi WWW, jest utwo- rzenie architektury na potrzeby integracji, która mo(cid:276)e okaza(cid:232) si(cid:246) uniwersalna w przypadku 22 (cid:95) Rozdzia(cid:293) 1. Magistrala ESB — wprowadzenie Kup książkęPoleć książkę rozbudowanego przedsi(cid:246)biorstwa (i nie tylko). Aby infrastruktura integracji mog(cid:228)a osi(cid:241)gn(cid:241)(cid:232) tak(cid:241) uniwersalno(cid:264)(cid:232), musi cechowa(cid:232) si(cid:246) nast(cid:246)puj(cid:241)cymi w(cid:228)a(cid:264)ciwo(cid:264)ciami. (cid:120) Musi zapewnia(cid:232) mo(cid:276)liwo(cid:264)(cid:232) adaptowania do potrzeb projektów integracji ogólnego zasto- sowania w przypadku ró(cid:276)nych scenariuszy integracyjnych (du(cid:276)e i ma(cid:228)e projekty). Mo(cid:276)liwo(cid:264)(cid:232) dostosowania obejmuje udost(cid:246)pnienie trwa(cid:228)ej architektury, która poradzi sobie z nieko- rzystnymi zmianami w protoko(cid:228)ach, z technologi(cid:241) interfejsu, a nawet z trendami mode- lowania procesów. (cid:120) Musi (cid:228)(cid:241)czy(cid:232) ze sob(cid:241) aplikacje, które obejmuj(cid:241) swoim zasi(cid:246)giem rozbudowane przedsi(cid:246)- biorstwo, za pomoc(cid:241) jednolitego rozwi(cid:241)zania i wspólnej infrastruktury. (cid:120) Musi si(cid:246)ga(cid:232) poza granice pojedynczego informatycznego centrum danych korporacji i auto- matyzowa(cid:232) relacje mi(cid:246)dzy partnerami, tak jak w przypadku scenariuszy B2B i (cid:228)a(cid:254)cucha dostaw. (cid:120) Musi oferowa(cid:232) prosty projekt i niewielkie wymagania pocz(cid:241)tkowe, umo(cid:276)liwiaj(cid:241)c prze- ci(cid:246)tnemu informatykowi zostanie kompetentnym architektem integracji. (cid:120) Musi zapewnia(cid:232) architektur(cid:246) SOA w ramach uniwersalnej integracji, która umo(cid:276)liwi ar- chitektom integracji uzyskanie mo(cid:276)liwo(cid:264)ci szerokiego spojrzenia na poziomie abstrakcji na korporacyjne zasoby aplikacyjne i zautomatyzowane procesy biznesowe. (cid:120) Musi zapewnia(cid:232) elastyczno(cid:264)(cid:232), a tak(cid:276)e mo(cid:276)liwo(cid:264)(cid:232) realizowania zmieniaj(cid:241)cych si(cid:246) wymaga(cid:254) biznesowych i reagowania na nie oraz na presj(cid:246) konkurencji. UWAGA W przypadku magistrali ESB aplikacje i us(cid:228)ugi sterowane zdarzeniami s(cid:241) ze sob(cid:241) po- wi(cid:241)zane w ramach architektury SOA w lu(cid:274)ny sposób. Umo(cid:276)liwia im to dzia(cid:228)anie niezale(cid:276)nie od siebie przy jednoczesnym oferowaniu korzy(cid:264)ci bardziej ogólnej funkcji biznesowej. Architektura magistrali ESB spe(cid:228)nia powy(cid:276)sze wymagania, a ponadto mo(cid:276)e zosta(cid:232) zaadaptowana na potrzeby dowolnego projektu integracji ogólnego zastosowania. Umo(cid:276)liwia równie(cid:276) wszech- obecne skalowanie w obr(cid:246)bie aplikacji korporacyjnych, niezale(cid:276)nie od po(cid:228)o(cid:276)enia fizycznego i plat- formy technologicznej. Dowolna aplikacja mo(cid:276)e zosta(cid:232) pod(cid:228)(cid:241)czona do sieci magistrali ESB przy u(cid:276)yciu kilku opcji (cid:228)(cid:241)czno(cid:264)ci, a nast(cid:246)pnie od razu uczestniczy(cid:232) we wspó(cid:228)u(cid:276)ytkowaniu danych z innymi aplikacjami, które ujawniono w magistrali jako us(cid:228)ugi wspó(cid:228)u(cid:276)ytkowane. Z tego po- wodu magistrala ESB cz(cid:246)sto jest okre(cid:264)lana mianem sieci integracji (ang. integration network) lub struktury integracji (ang. integration fabric). Magistrala ESB zapewnia podej(cid:264)cie cechuj(cid:241)ce si(cid:246) wysokim stopniem rozproszenia, oferuj(cid:241)c uni- kalne mo(cid:276)liwo(cid:264)ci, które pozwalaj(cid:241) poszczególnym dzia(cid:228)om lub jednostkom biznesowym tworzy(cid:232) ich projekty integracji w ramach powi(cid:246)kszaj(cid:241)cych si(cid:246) stopniowo porcji. Korzystaj(cid:241)c z magistrali ESB, dzia(cid:228)y lub jednostki biznesowe mog(cid:241) nadal zachowa(cid:232) w(cid:228)asn(cid:241) lokaln(cid:241) kontrol(cid:246) i auto- nomi(cid:246) w poszczególnych projektach integracji, a jednocze(cid:264)nie mie(cid:232) mo(cid:276)liwo(cid:264)(cid:232) po(cid:228)(cid:241)czenia ka(cid:276)dego projektu integracji z wi(cid:246)ksz(cid:241), bardziej globaln(cid:241) sieci(cid:241) lub struktur(cid:241) integracji. Architektura SOA dla us(cid:293)ug WWW Us(cid:228)ugi WWW sprawi(cid:228)y, (cid:276)e na nowo odkryto wa(cid:276)no(cid:264)(cid:232) architektur zorientowanych na us(cid:228)ugi. Us(cid:228)ugi WWW zapewniaj(cid:241) opart(cid:241) na standardach metod(cid:246) wspó(cid:228)dzia(cid:228)ania aplikacji. G(cid:228)ównym celem us(cid:228)ug WWW by(cid:228)o zapewnienie abstrakcji us(cid:228)ug, która umo(cid:276)liwia wspó(cid:228)dzia(cid:228)anie aplikacji Architektura SOA dla us(cid:293)ug WWW (cid:95) 23 Kup książkęPoleć książkę utworzonych z wykorzystaniem odmiennych platform i (cid:264)rodowisk. Osi(cid:241)gni(cid:246)cie tego celu za- pewni prostsz(cid:241) (cid:264)cie(cid:276)k(cid:246) do uzyskania uniwersalnej integracji aplikacji. Po pojawieniu si(cid:246) magistrali ESB zaistnia(cid:228)a metoda w(cid:228)(cid:241)czenia us(cid:228)ug WWW i architektury SOA do znacz(cid:241)cej architektury integruj(cid:241)cej na du(cid:276)(cid:241) skal(cid:246) aplikacje i us(cid:228)ugi ze szkieletem, który swoim za- si(cid:246)giem obejmuje rozbudowane przedsi(cid:246)biorstwo. Magistrala ESB sprawia, (cid:276)e us(cid:228)ugi WWW, format XML i inne technologie integracyjne staj(cid:241) si(cid:246) natychmiast przydatne w przypadku dojrza(cid:228)ej technologii, która istnieje obecnie. Podstawowe za(cid:228)o(cid:276)enia architektury SOA maj(cid:241) kluczowe znaczenie dla powodzenia uniwersal- nego projektu integracji. Ponadto s(cid:241) one ju(cid:276) do(cid:264)(cid:232) dok(cid:228)adnie zaimplementowane w magistrali ESB. Cho(cid:232) standardy us(cid:228)ug WWW rozwijaj(cid:241) si(cid:246) we w(cid:228)a(cid:264)ciwym kierunku, pozostaj(cid:241) niekom- pletne w odniesieniu do mo(cid:276)liwo(cid:264)ci korporacyjnych, takich jak zabezpieczenia, niezawodno(cid:264)(cid:232), zarz(cid:241)dzanie transakcjami i organizacja procesów biznesowych. W przypadku tych kwestii ma- gistrala ESB opiera si(cid:246) na ugruntowanych obecnie standardach, a ponadto jest wykorzysty- wana w praktycznych implementacjach, które zosta(cid:228)y ju(cid:276) wdro(cid:276)one w kilku bran(cid:276)ach. Magi- strala ESB ma spory potencja(cid:228), aby poradzi(cid:232) sobie z ci(cid:241)gle rozwijanymi odpowiednikami powy(cid:276)szych mo(cid:276)liwo(cid:264)ci powi(cid:241)zanymi z us(cid:228)ugami WWW, gdy stan(cid:241) si(cid:246) one bardziej dojrza- (cid:228)e. Szerzej zagadnienie to zosta(cid:228)o przedstawione w rozdziale 12. Tradycyjne metody integracji Magistrala ESB stosuje us(cid:228)ugi WWW oraz inne uzupe(cid:228)niaj(cid:241)ce standardy, (cid:228)(cid:241)cz(cid:241)c je z zagadnie- niami technologicznymi i ze sprawdzonymi procedurami, które pochodz(cid:241) z brokerów EAI. Magistrala ESB jest jednak czym(cid:264) wi(cid:246)cej ni(cid:276) tylko „opakowaniem” us(cid:228)ug WWW umieszczonym ponad tym samym poczciwym koncentratorem EAI. Tradycyjnie zdefiniowane metody integracji maj(cid:241) swoje zalety i wady. Na rysunku 1.1 pokazano cz(cid:246)(cid:264)(cid:232) ogólnych w(cid:228)a(cid:264)ciwo(cid:264)ci metod integracji, które rozmieszczono od najmniej (lewy dolny prostok(cid:241)t) do najbardziej po(cid:276)(cid:241)danych (prawy górny prostok(cid:241)t). Rysunek 1.1. W(cid:228)a(cid:264)ciwo(cid:264)ci tradycyjnych brokerów EAI, serwerów aplikacji, zwyk(cid:228)ego oprogramowania MOM i magistrali ESB 24 (cid:95) Rozdzia(cid:293) 1. Magistrala ESB — wprowadzenie Kup książkęPoleć książkę Tradycyjne brokery EAI, które obejmuj(cid:241) brokery budowane na podstawie serwerów aplikacji, korzystaj(cid:241) z architektury z konfiguracj(cid:241) gwia(cid:274)dzist(cid:241). Oferuje ona korzy(cid:264)(cid:232) w postaci scentrali- zowanych funkcji, takich jak zarz(cid:241)dzanie logik(cid:241) routingu i regu(cid:228)ami biznesowymi, ale nie jest zbyt dobrze skalowana poza granicami dzia(cid:228)ów lub jednostek biznesowych. W rozdziale 2. zosta(cid:228)y przedstawione przybli(cid:276)one spore koszty wczesnych prób integracji przy u(cid:276)yciu kon- centratorów EAI, a tak(cid:276)e umiarkowany sukces tych koncentratorów. Serwery aplikacji mog(cid:241) wspó(cid:228)pracowa(cid:232) za po(cid:264)rednictwem standardowych protoko(cid:228)ów, a przy tym (cid:228)(cid:241)czy(cid:232) (cid:264)ci(cid:264)le ze sob(cid:241) ró(cid:276)ne rzeczy, a tak(cid:276)e wi(cid:241)za(cid:232) logik(cid:246) integracji z logik(cid:241) aplikacji. Brokery EAI zapewniaj(cid:241) zwi(cid:246)kszon(cid:241) warto(cid:264)(cid:232), oddzielaj(cid:241)c logik(cid:246) aplikacji od logiki integracji i routingu procesów, ale jednak nadal opieraj(cid:241)c si(cid:246) na nie najlepszej architekturze z konfigu- racj(cid:241) gwia(cid:274)dzist(cid:241). Oprogramowanie po(cid:264)rednie zorientowane na komunikaty (MOM — Message Oriented Midd- leware) zapewnia mo(cid:276)liwo(cid:264)(cid:232) lu(cid:274)nego (cid:228)(cid:241)czenia aplikacji w asynchroniczny sposób. Samo oprogra- mowanie MOM wymaga jednak kodowania niskopoziomowego w aplikacji. U(cid:276)ycie tradycyj- nego oprogramowania MOM wraz z niestandardowymi technikami kodowania nie zapewni mo(cid:276)liwo(cid:264)ci szybkiego uzyskania rozwi(cid:241)zania integracji rozproszonej. Jednak(cid:276)e bez wy(cid:276)szego poziomu abstrakcji logiki routingu ta metoda traci tak(cid:276)e w wyniku trwa(cid:228)ego powi(cid:241)zania lo- giki integracji z logik(cid:241) aplikacji. Zale(cid:276)nie od rodzaju u(cid:276)ywanego oprogramowania MOM, ograniczona mo(cid:276)e by(cid:232) nawet w(cid:228)a(cid:264)ciwo(cid:264)(cid:232) rozproszenia, poniewa(cid:276) tradycyjna infrastruktura MOM nie ma zbyt du(cid:276)ych mo(cid:276)liwo(cid:264)ci pokonywania granic sieci fizycznych. Z kolei w przypadku magistrali ESB us(cid:228)ugi mog(cid:241) by(cid:232) konfigurowane, a nie kodowane. Przep(cid:228)yw procesów i wywo(cid:228)ania us(cid:228)ug mog(cid:241) w transparentny sposób obejmowa(cid:232) swoim zasi(cid:246)giem ca(cid:228)(cid:241) rozproszon(cid:241) magistral(cid:246). Magistrala ESB zapewnia wysoce rozproszone (cid:264)rodowisko integracji, którego zasi(cid:246)g znacznie przekracza mo(cid:276)liwo(cid:264)ci architektur z konfiguracj(cid:241) gwia(cid:274)dzist(cid:241). Po- nadto magistrala wyra(cid:274)nie oddziela logik(cid:246) biznesow(cid:241) od logiki integracji (np. routing i transfor- macj(cid:246) danych). Architektura magistrali ESB tworzy siatk(cid:246) wzajemnie po(cid:228)(cid:241)czonych koncentrato- rów przesy(cid:228)ania komunikatów i us(cid:228)ug integracji, cechuj(cid:241)c(cid:241) si(cid:246) inteligencj(cid:241) i funkcjonalno(cid:264)ci(cid:241) rozproszonej sieci integracji. W rozdziale 6. dok(cid:228)adniej opisano ró(cid:276)nic(cid:246) mi(cid:246)dzy integracj(cid:241) opart(cid:241) na architekturze serwera aplikacji i integracj(cid:241) z wykorzystaniem magistrali ESB. Poj(cid:246)cia zwi(cid:241)zane z oprogramowaniem MOM przedstawiono w rozdziale 5. W punkcie „Przypadkowa architektura” rozdzia(cid:228)u 2. kontynuowane jest omówienie rozdzielenia routingu procesów biznesowych i logiki biznesowej. Wymagania okre(cid:316)lane potrzebami dzia(cid:293)u informatycznego Kluczow(cid:241) cech(cid:241) magistrali ESB jest zapewnianie fundamentów do obs(cid:228)ugi wymaga(cid:254) rozpro- szonych i lu(cid:274)no powi(cid:241)zanych jednostek biznesowych oraz partnerów biznesowych, którzy automatyzuj(cid:241) (cid:228)a(cid:254)cuchy dostaw. Takie mo(cid:276)liwo(cid:264)ci pojawi(cid:228)y si(cid:246) w magistrali ESB z potrzeby, jako wynik wspó(cid:228)pracy dostawców oprogramowania po(cid:264)redniego z ekspertami bran(cid:276)owymi — wszyscy oni próbowali stworzy(cid:232) architektur(cid:246) na potrzeby integracji o du(cid:276)ej skali. W(cid:264)ród tych ekspertów byli architekci pracuj(cid:241)cy w dzia(cid:228)ach informatycznych wi(cid:246)kszych korporacji oraz innowatorzy ze spo(cid:228)eczno(cid:264)ci powi(cid:241)zanej z platformami handlu elektronicznego. Wymagali Wymagania okre(cid:316)lane potrzebami dzia(cid:293)u informatycznego (cid:95) 25 Kup książkęPoleć książkę oni zbudowania szkieletu wymiany handlowej B2B na podstawie: us(cid:228)ug wspó(cid:228)u(cid:276)ytkowanych, przesy(cid:228)ania komunikatów, j(cid:246)zyka XML i kilku opcji (cid:228)(cid:241)czno(cid:264)ci, a tak(cid:276)e z zachowaniem zgod- no(cid:264)ci ze standardami bran(cid:276)owymi w przypadku ka(cid:276)dego komponentu. W rozdziale 3. za- prezentowano wiele katalizatorów, które przyczyni(cid:228)y si(cid:246) do powstania magistrali ESB. Najpowa(cid:276)niejsze wymagania, które musia(cid:228)y jeszcze zosta(cid:232) spe(cid:228)nione, dotyczy(cid:228)y efektywnego udost(cid:246)pniania mo(cid:276)liwo(cid:264)ci integracji, takich jak adaptery aplikacji, transformacja danych i inte- ligentny routing, w sposób pozwalaj(cid:241)cy na u(cid:276)ycie ich w projektach integracji ogólnego zasto- sowania w przypadku ró(cid:276)nych scenariuszy integracji. Potrzebna by(cid:228)a równie(cid:276) bardziej uni- wersalna technologia oraz rozwi(cid:241)zania architektury, które mog(cid:228)yby zosta(cid:232) u(cid:276)yte do (cid:228)(cid:241)czenia aplikacji bez wzgl(cid:246)du na wymagania poszczególnych taktycznych projektów integracji. Informatycy rozczarowali si(cid:246) niektórymi wcze(cid:264)niejszymi trendami technologicznymi, takimi jak CORBA i EAI. Technologia CORBA by(cid:228)a w(cid:228)a(cid:264)ciwym pomys(cid:228)em w przypadku architektu- ry SOA, ale okaza(cid:228)a si(cid:246) zbyt z(cid:228)o(cid:276)ona do zaimplementowania i utrzymania z powodu zale(cid:276)no(cid:264)ci od (cid:264)ci(cid:264)le powi(cid:241)zanych interfejsów mi(cid:246)dzy aplikacjami i us(cid:228)ugami. Technologia EAI równie(cid:276) ma wady w postaci wymogu po(cid:264)wi(cid:246)cenia du(cid:276)ej ilo(cid:264)ci czasu na jej opanowanie oraz du(cid:276)ych kosztów wprowadzenia do poszczególnych projektów (wi(cid:246)cej na ten temat napisano w na- st(cid:246)pnym rozdziale). W rzeczywisto(cid:264)ci potrzebne by(cid:228)o proste podej(cid:264)cie wzgl(cid:246)dem architektu- ry SOA, która mog(cid:228)aby by(cid:232) adaptowana pod k(cid:241)tem ogólnych wymaga(cid:254) dowolnego projektu integracji, niezale(cid:276)nie czy du(cid:276)ego, czy ma(cid:228)ego. Ponadto niezb(cid:246)dna by(cid:228)a trwa(cid:228)a architektura odporna na rozwój protoko(cid:228)ów, technologii interfejsów, a nawet trendów modelowania pro- cesów. Magistrala ESB zosta(cid:228)a utworzona z my(cid:264)l(cid:241) o spe(cid:228)nieniu wszystkich tych wymaga(cid:254). Zainteresowanie ze strony bran(cid:348)y Od czasu, gdy magistrala ESB pojawi(cid:228)a si(cid:246) po raz pierwszy (w 2002 r.), to rozwi(cid:241)zanie na potrzeby integracji zosta(cid:228)o zaadaptowane przez kilku znacz(cid:241)cych dostawców obecnych na ryn- ku oprogramowania po(cid:264)rednicz(cid:241)cego, integracji i us(cid:228)ug WWW. Popularno(cid:264)(cid:232) magistrali ESB ca(cid:228)y czas równomiernie si(cid:246) zwi(cid:246)ksza. Od pocz(cid:241)tku 2002 r. firmy analityczne, takie jak Gartner Inc., IDC i ZapThink, du(cid:276)o pisz(cid:241) na temat technologii ESB i (cid:264)ledz(cid:241) jej rozwój. W raporcie opublikowanym w 2002 r. (DF-18-7304) Roy Schulte, analityk z firmy Gartner Inc., zawar(cid:228) nast(cid:246)puj(cid:241)ce informacje: Nowa posta(cid:232) infrastruktury magistrali us(cid:228)ug korporacyjnych ESB, która (cid:228)(cid:241)czy w sobie oprogra- mowanie po(cid:264)rednicz(cid:241)ce zorientowane na us(cid:228)ugi, us(cid:228)ugi WWW, transformacj(cid:246) i inteligencj(cid:246) routingu, do 2005 r. b(cid:246)dzie wykorzystywana przez wi(cid:246)kszo(cid:264)(cid:232) przedsi(cid:246)biorstw. Te zaawansowane i tanie magistrale ESB s(cid:241) odpowiednio dostosowane do pe(cid:228)nienia funkcji szkieletu na potrzeby architektur zorientowanych na us(cid:228)ugi oraz „systemu nerwowego” przed- si(cid:246)biorstw. Te cztery filary, czyli oprogramowanie MOM, us(cid:228)ugi WWW, transformacja i inteligencja routingu, reprezentuj(cid:241) fundament ka(cid:276)dej dobrej magistrali ESB. W ksi(cid:241)(cid:276)ce skoncentrowano si(cid:246) na roli ka(cid:276)dego z tych elementów, a tak(cid:276)e wielu innych niezb(cid:246)dnych komponentów, które pojawi(cid:241) si(cid:246) podczas poznawania magistrali ESB. Dowiesz si(cid:246), jakie mo(cid:276)liwo(cid:264)ci magistrala ESB oferuje przedsi(cid:246)biorstwu, jak równie(cid:276) jak(cid:241) rol(cid:246) odgrywa ka(cid:276)dy podstawowy komponent. Zapre- zentujemy tak(cid:276)e kilka zaawansowanych zagadnie(cid:254), w tym przegl(cid:241)d architektur praktycznie wykorzystywanych w kilku bran(cid:276)ach. 26 (cid:95) Rozdzia(cid:293) 1. Magistrala ESB — wprowadzenie Kup książkęPoleć książkę Dostawcy adaptuj(cid:233)cy magistral(cid:253) ESB Kilku dostawców oprogramowania po(cid:264)rednicz(cid:241)cego i technologii integracji stworzy(cid:228)o (lub jest w trakcie tworzenia) co(cid:264) zgodnego z opisem magistrali ESB. Lista dostawców ca(cid:228)y czas si(cid:246) powi(cid:246)ksza. W dodatku do ksi(cid:241)(cid:276)ki wyszczególniono wszystkich znanych dostawców. Niektórzy dostawcy twierdz(cid:241), (cid:276)e ju(cid:276) udost(cid:246)pniaj(cid:241) magistral(cid:246) ESB. Cz(cid:246)(cid:264)(cid:232) z nich og(cid:228)osi(cid:228)a plany jej utworze- nia. Cho(cid:232) cz(cid:246)(cid:264)(cid:232) dostawców pos(cid:228)uguje si(cid:246) odpowiedni(cid:241) terminologi(cid:241) w materia(cid:228)ach marketin- gowych, w rzeczywisto(cid:264)ci nie kryje si(cid:246) za tym nic znacz(cid:241)cego. Ta kategoria technologii stanie si(cid:246) tak popularna jak serwery aplikacji pod koniec lat 90., gdy ponad dwudziestu pi(cid:246)ciu dostawców rywalizowa(cid:228)o w przypadku tej samej technologii. Kilku dostawców na li(cid:264)cie zas(cid:228)uguje na szczególn(cid:241) uwag(cid:246). Firma Sonic Software jest pionie- rem w dziedzinie magistral ESB. Nied(cid:228)ugo po niej kilku innych mniejszych dostawców zacz(cid:246)(cid:228)o ze sob(cid:241) rywalizowa(cid:232), g(cid:228)osz(cid:241)c, (cid:276)e równie(cid:276) udost(cid:246)pnili magistral(cid:246) ESB lub s(cid:241) w trakcie jej tworzenia. Gdy czo(cid:228)owe firmy z bran(cid:276)y integracji, takie jak webMethods, SeeBeyond i IBM, wreszcie po- stanowi(cid:228)y wkroczy(cid:232) do akcji, og(cid:228)aszaj(cid:241)c zamiar zbudowania w(cid:228)asnych magistrali ESB, to poj(cid:246)- cie naprawd(cid:246) zyska(cid:228)o szeroki rozg(cid:228)os jako rozwijaj(cid:241)ca si(cid:246) kategoria niezawodnej technologii. Gdy pisano ksi(cid:241)(cid:276)k(cid:246), firma Microsoft nie przekaza(cid:228)a opinii publicznej (cid:276)adnych o(cid:264)wiadcze(cid:254) dotycz(cid:241)cych jej projektu Indigo i magistrali ESB. Jednak(cid:276)e niektórzy dziennikarze i analitycy odkryli takie powi(cid:241)zanie, gdy po raz pierwszy og(cid:228)oszono informacje o projekcie Indigo. W ar- tykule zatytu(cid:228)owanym Developer interest piqued by Microsoft technologies (Ciekawo(cid:264)(cid:232) programisty wywo(cid:228)ana przez technologie firmy Microsoft), który pojawi(cid:228) si(cid:246) w magazynie „ComputerWorld” z 30 listopada 2003 r., zacytowano wypowied(cid:274) Roya Schulte z Gartner Inc. Oto tre(cid:264)(cid:232) notki: Roy Schulte, analityk z firmy Gartner Inc. z siedzib(cid:241) w Stamford, w stanie Connecticut, za- uwa(cid:276)y(cid:228), (cid:276)e projekt Indigo to nadzbiór technologii MSMQ (Microsoft Messaging Queuing), a tak- (cid:276)e implementacji firmy Microsoft, które obs(cid:228)uguj(cid:241) technologie COM (Component Object Model), COM+, .Net Remoting i us(cid:228)ugi WWW. „Potraktujcie to jako uproszczenie, unifikacj(cid:246) komuni- kacyjnego oprogramowania po(cid:264)rednicz(cid:241)cego z my(cid:264)l(cid:241) o planach Microsoftu” — stwierdzi(cid:228) Roy, dodaj(cid:241)c, (cid:276)e postrzega projekt Indigo jako bardzo dobr(cid:241) magistral(cid:246) us(cid:228)ug korporacyj- nych ESB. Projekt Indigo oparty jest na przesy(cid:228)aniu komunikatów. Ponadto wiadomo, (cid:276)e (cid:228)(cid:241)czy w sobie technologi(cid:246) MSMQ i us(cid:228)ugi WWW. Mog(cid:228)o to zapewni(cid:232) fundament magistrali przesy(cid:228)ania komunikatów. Reszta funkcji integracji tego projektu jest jednak zawarta w oprogramowaniu BizTalk, które jest serwerem integracji z konfiguracj(cid:241) gwia(cid:274)dzist(cid:241). Aby projekt zakwalifikowa(cid:232) jako magistral(cid:246) ESB, musz(cid:241) istnie(cid:232) zarówno rozproszona magistrala komunikatów, jak i roz- proszone funkcje integracji. Zrealizowanie projektu Indigo spowoduje przynajmniej, (cid:276)e aplikacje i us(cid:228)ugi oparte na platformie firmy Microsoft stan(cid:241) si(cid:246) jeszcze bardziej atrakcyjne jako punkty ko(cid:254)cowe umo(cid:276)liwiaj(cid:241)ce pod(cid:228)(cid:241)czenie do magistrali ESB. Do(cid:228)(cid:241)czenie projektu Indigo do platformy Microsoftu i (cid:264)rodo- wiska programistycznego u(cid:228)atwi tworzenie aplikacji, które mog(cid:241) by(cid:232) lu(cid:274)no powi(cid:241)zane, a po- nadto obs(cid:228)uguj(cid:241) przesy(cid:228)anie komunikatów. Zainteresowanie ze strony bran(cid:348)y (cid:95) 27 Kup książkęPoleć książkę W(cid:293)a(cid:316)ciwo(cid:316)ci magistrali ESB Z powodu szybkiego wzrostu liczby dostawców próbuj(cid:241)cych zainteresowa(cid:232) klientów rozwijaj(cid:241)c(cid:241) si(cid:246) kategori(cid:241) produktów ESB, a tak(cid:276)e wielu analityków i dziennikarzy bran(cid:276)owych prezentuj(cid:241)- cych swoje opinie na temat magistrali ESB oczywiste jest spore niezrozumienie tego, czym ona w rzeczywisto(cid:264)ci jest. W tym podrozdziale przedstawiono g(cid:228)ówne w(cid:228)a(cid:264)ciwo(cid:264)ci magistrali ESB. Wszechobecno(cid:316)(cid:235) Jak pokazano na rysunku 1.2, magistrala ESB mo(cid:276)e stanowi(cid:232) rdze(cid:254) wszechobecnej siatki. Swoim zasi(cid:246)giem mo(cid:276)e obejmowa(cid:232) rozbudowane przedsi(cid:246)biorstwo (i nie tylko), oferuj(cid:241)c globalny dost(cid:246)p mi(cid:246)dzy organizacjami dzia(cid:228)ów, jednostkami biznesowymi i partnerami handlowymi. Magi- strala ESB jest te(cid:276) dobrze dopasowana do lokalnych projektów integracji, a ponadto zapew- nia cechuj(cid:241)cy si(cid:246) elastyczno(cid:264)ci(cid:241) fundament, który umo(cid:276)liwia przystosowanie magistrali do dowolnego typu (cid:264)rodowiska integracji. Rysunek 1.2. Magistrala ESB tworzy wszechobecn(cid:241) siatk(cid:246), która swoim zasi(cid:246)giem mo(cid:276)e obejmowa(cid:232) globaln(cid:241) sie(cid:232) korporacyjn(cid:241) Aplikacje s(cid:241) pod(cid:228)(cid:241)czane do magistrali w razie potrzeby, a ponadto maj(cid:241) mo(cid:276)liwo(cid:264)(cid:232) wy(cid:264)wie- tlania danych oraz wspó(cid:228)u(cid:276)ytkowania ich z dowolnymi innymi aplikacjami lub us(cid:228)ugami, które s(cid:241) pod(cid:228)(cid:241)czane do magistrali. Cho(cid:232) interfejsy us(cid:228)ug WWW stanowi(cid:241) integraln(cid:241) cz(cid:246)(cid:264)(cid:232) ar- chitektury magistrali ESB, (cid:276)adna aplikacja nie musi by(cid:232) modyfikowana, aby sta(cid:228)a si(cid:246) prawdzi- w(cid:241) us(cid:228)ug(cid:241) WWW, uczestnicz(cid:241)c(cid:241) w magistrali ESB. (cid:227)(cid:241)czno(cid:264)(cid:232) jest osi(cid:241)gana za po(cid:264)rednictwem wielu protoko(cid:228)ów, technologii interfejsu API klienta, starszych (cid:264)rodowisk przesy(cid:228)ania komu- nikatów oraz niezale(cid:276)nych adapterów aplikacji. 28 (cid:95) Rozdzia(cid:293) 1. Magistrala ESB — wprowadzenie Kup książkęPoleć książkę Integracja oparta na standardach Integracja oparta na standardach to zasadnicze poj(cid:246)cie zwi(cid:241)zane z magistral(cid:241) ESB. Na potrzeby (cid:228)(cid:241)czno(cid:264)ci mo(cid:276)e ona wykorzystywa(cid:232) komponenty J2EE, takie jak JMS (Java Message Service; do obs(cid:228)ugi (cid:228)(cid:241)czno(cid:264)ci oprogramowania MOM) i JCA lub J2CA (J2EE Connector Architecture; do obs(cid:228)ugi po(cid:228)(cid:241)cze(cid:254) z adapterami aplikacji). Magistrala ESB integruje si(cid:246) dobrze równie(cid:276) z apli- kacjami opartymi na technologiach .NET, COM, C# i C/C++. Poza tym magistrala mo(cid:276)e z (cid:228)atwo- (cid:264)ci(cid:241) zosta(cid:232) zintegrowana z czymkolwiek, co obs(cid:228)uguje protokó(cid:228) SOAP i interfejsy API us(cid:228)ug WWW (de facto obejmuje to standardowe implementacje pakietu narz(cid:246)dzi us(cid:228)ug WWW, ta- kie jak np. Apache Axis). Na potrzeby przetwarzania danych magistrala ESB mo(cid:276)e u(cid:276)ywa(cid:232) standardów XML, takich jak XSLT, XPath i XQuery, aby zapewni(cid:232) transformacj(cid:246) danych, inteli- gentny routing i odpytywanie danych „w trakcie zatwierdzania”, które przep(cid:228)ywaj(cid:241) przez magistral(cid:246). W celu obs(cid:228)ugi architektury SOA i routingu procesów biznesowych magistrala ESB mo(cid:276)e korzysta(cid:232) z j(cid:246)zyka WSDL (Web Services Description Language) s(cid:228)u(cid:276)(cid:241)cego do opisu abstrak- cyjnych interfejsów us(cid:228)ug, j(cid:246)zyka BPEL4WS (Business Process Execution Language for Web Services), specyfikacji WS-Choreography lub jakiego(cid:264) innego s(cid:228)ownika opartego na j(cid:246)zyku XML (np. ebXML BPSS) do opisu abstrakcyjnych procesów biznesowych. Nie ma powodu do obaw, je(cid:264)li nie wiesz, co oznaczaj(cid:241) wszystkie te modne terminy. Cho(cid:232) ksi(cid:241)(cid:276)ka nie ma by(cid:232) traktowana jako kompletny materia(cid:228) referencyjny lub podr(cid:246)cznik po(cid:264)wi(cid:246)- cony wszystkim wymienionym technologiom, zostan(cid:241) one obja(cid:264)nione wystarczaj(cid:241)co dok(cid:228)adnie w kontek(cid:264)cie ich powi(cid:241)zania z magistral(cid:241) ESB. Te oparte na standardach interfejsy i komponenty s(cid:241) ze sob(cid:241) zestawiane w sensowny sposób, który pozwala uzyska(cid:232) elastyczn(cid:241), pod(cid:228)(cid:241)czan(cid:241) architektur(cid:246). Magistrala ESB zapewnia infra- struktur(cid:246), która obs(cid:228)uguje zarówno b(cid:246)d(cid:241)ce standardem w bran(cid:276)y komponenty integracji, jak i elementy niestandardowe przy u(cid:276)yciu standaryzowanych interfejsów. Na rysunku 1.3 po- kazano uproszczony widok magistrali ESB integruj(cid:241)cej aplikacj(cid:246) J2EE za pomoc(cid:241) technologii JMS i JCA, zewn(cid:246)trzn(cid:241) aplikacj(cid:246) w postaci pakietu przy u(cid:276)yciu adaptera aplikacji zgodnego z technologi(cid:241) JCA, aplikacj(cid:246) .NET z wykorzystaniem klienta C# oraz dwie zewn(cid:246)trzne aplikacje przy u(cid:276)yciu us(cid:228)ug WWW. Integracja o wysokim stopniu rozproszenia i wdra(cid:348)anie selektywne Magistrala ESB przypomina tradycyjn(cid:241) funkcjonalno(cid:264)(cid:232) brokera EAI pod tym wzgl(cid:246)dem, (cid:276)e zapewnia us(cid:228)ugi integracji, takie jak organizowanie procesów biznesowych i routing danych, transformacj(cid:246) danych i adaptery aplikacji. Jednak(cid:276)e z natury brokery integracji cechuj(cid:241) si(cid:246) zwykle monolityczno(cid:264)ci(cid:241) i wysokim stopniem scentralizowania. Magistrala ESB oferuje takie mo(cid:276)liwo(cid:264)ci integracji jako osobne us(cid:228)ugi, które mog(cid:241) wspó(cid:228)pracowa(cid:232) w sposób cechuj(cid:241)cy si(cid:246) wysokim poziomem rozproszenia. Ponadto mog(cid:241) one by(cid:232) skalowane niezale(cid:276)nie od siebie. W rozdziale 6. zamieszczono wi(cid:246)cej informacji na temat „kontenera us(cid:228)ug” magistrali ESB. Jest to podstawowe poj(cid:246)cie zwi(cid:241)zane z magistral(cid:241) ESB, umo(cid:276)liwiaj(cid:241)ce selektywne wdra(cid:276)anie us(cid:228)ug integracji. W(cid:293)a(cid:316)ciwo(cid:316)ci magistrali ESB (cid:95) 29 Kup książkęPoleć książkę Rysunek 1.3. Magistrala ESB integruj(cid:241)ca odmienne technologie Transformacja danych rozproszonych Kluczowym elementem dowolnej strategii integracji jest mo(cid:276)liwo(cid:264)(cid:232) (cid:228)atwego konwertowania formatów danych mi(cid:246)dzy aplikacjami. Wiele aplikacji nie u(cid:276)ywa tego samego formatu do opisu podobnych danych. Transformacja danych to naturalny element magistrali we wdro(cid:276)eniu ESB. Us(cid:228)ugi transformacji, które maj(cid:241) za zadanie spe(cid:228)nianie wymaga(cid:254) poszczególnych aplikacji pod(cid:228)(cid:241)czanych do magi- strali, mog(cid:241) si(cid:246) znajdowa(cid:232) w dowolnej lokalizacji i by(cid:232) dost(cid:246)pne w ka(cid:276)dym miejscu magi- strali. Ze wzgl(cid:246)du na to, (cid:276)e transformacja danych stanowi integraln(cid:241) cz(cid:246)(cid:264)(cid:232) samej magistrali ESB, mo(cid:276)na j(cid:241) uzna(cid:232) za eliminuj(cid:241)c(cid:241) niezgodno(cid:264)(cid:232) impedancji mi(cid:246)dzy aplikacjami. Rozszerzalno(cid:316)(cid:235) za po(cid:316)rednictwem us(cid:293)ug warstwowych Magistrala ESB udost(cid:246)pnia wszystkie wymagane podstawowe funkcje dla niemal ka(cid:276)dego projektu integracji. Ponadto mo(cid:276)e zosta(cid:232) rozszerzona przy u(cid:276)yciu technologii warstwowej w celu obs(cid:228)ugi bardziej specyficznych zastosowa(cid:254). Na przyk(cid:228)ad specjalistyczne rozwi(cid:241)zania, takie jak oprogramowania do zarz(cid:241)dzania procesami biznesowymi (BPM — Business Process Manage- ment), mog(cid:241) przetwarza(cid:232) procesy biznesowe powi(cid:241)zane z przep(cid:228)ywem pracy. Z kolei serwery obs(cid:228)uguj(cid:241)ce prac(cid:246) grupow(cid:241) mog(cid:241) zapewnia(cid:232) specjalistyczne us(cid:228)ugi do zarz(cid:241)dzania partnerami biz- nesowymi. Specjalistyczne, zewn(cid:246)trzne translatory mog(cid:241) oferowa(cid:232) konwersj(cid:246) danych z zewn(cid:246)trz- nych formatów, takich jak EDI, na formaty docelowego systemu ERP (Enterprise Resource Planning) lub, w przypadku ogólnej magistrali, na posta(cid:232) wewn(cid:246)trznej, kanonicznej reprezentacji XML. 30 (cid:95) Rozdzia(cid:293) 1. Magistrala ESB — wprowadzenie Kup książkęPoleć książkę Architektura SOA sterowana zdarzeniami W przypadku architektury SOA sterowanej zdarzeniami z obs(cid:228)ug(cid:241) magistrali ESB aplikacje i us(cid:228)ugi s(cid:241) traktowane jako abstrakcyjne punkty ko(cid:254)cowe us(cid:228)ug, z (cid:228)atwo(cid:264)ci(cid:241) mog(cid:241)ce odpowiada(cid:232) na zdarzenia asynchroniczne. Architektura SOA zapewnia abstrakcj(cid:246) pozbawion(cid:241) ukrytych szczegó(cid:228)ów dotycz(cid:241)cych (cid:228)(cid:241)czno(cid:264)ci i pod(cid:228)(cid:241)czania. Implementacje us(cid:228)ug nie wymagaj(cid:241) rozpo- znawania protoko(cid:228)ów. Us(cid:228)ugom nie musi by(cid:232) znany sposób kierowania komunikatów do in- nych us(cid:228)ug. Us(cid:228)ugi po prostu odbieraj(cid:241) komunikat z magistrali ESB jako zdarzenie i przetwa- rzaj(cid:241) go. Magistrala kieruje komunikat w dowolne miejsce, do którego ma on trafi(cid:232). W architekturze SOA z obs(cid:228)ug(cid:241) magistrali ESB niestandardowe us(cid:228)ugi integracji mog(cid:241) by(cid:232) tworzone, rozszerzane i ponownie wykorzystywane jako funkcjonalno(cid:264)(cid:232) magistrali ESB. Punkty ko(cid:254)cowe aplikacji, ujawniane jako us(cid:228)ugi, mog(cid:241) by(cid:232) konstruowane razem ze specjalistycz- nymi elementami w(cid:228)(cid:241)czaj(cid:241)cymi w celu utworzenia us(cid:228)ug z(cid:228)o(cid:276)onych i przep(cid:228)ywów procesów. Mog(cid:241) one by(cid:232) ponownie (cid:228)(cid:241)czone i wykorzystywane do ró(cid:276)nych celów z zamiarem zauto- matyzowania funkcji biznesowych w rzeczywistym przedsi(cid:246)biorstwie. W rozdziale 7. bardziej szczegó(cid:228)owo omówiono architektur(cid:246) SOA z obs(cid:228)ug(cid:241) magistrali ESB. Przep(cid:293)yw procesu Mo(cid:276)liwo(cid:264)ci przep(cid:228)ywu procesów magistrali ESB obejmuj(cid:241) swoim zasi(cid:246)giem zarówno proste sekwencje ograniczonych kroków, jak i zaawansowane organizowanie procesów biznesowych z u(cid:276)yciem równoleg(cid:228)ych (cid:264)cie(cid:276)ek wykonywania procesów za pomoc(cid:241) podzia(cid:228)ów i po(cid:228)(cid:241)cze(cid:254) warunkowych. Mog(cid:241) one by(cid:232) kontrolowane przy u(cid:276)yciu prostych metadanych komunikatów lub za po(cid:264)rednictwem j(cid:246)zyka organizowania, takiego jak BPEL4WS. Funkcje przep(cid:228)ywu procesu magistrali ESB umo(cid:276)liwiaj(cid:241) definiowanie procesów biznesowych, które s(cid:241) lokalne dla poszczególnych dzia(cid:228)ów lub jednostek biznesowych, a ponadto mog(cid:241) wspó(cid:228)- istnie(cid:232) w obr(cid:246)bie wi(cid:246)kszej sieci integracji. Jest to co(cid:264), czego we w(cid:228)asnym zakresie nie by(cid:228) w stanie zbyt dobrze zapewni(cid:232) ani broker integracji z konfiguracj(cid:241) gwia(cid:274)dzist(cid:241), ani narz(cid:246)dzie BPM. W rozdziale 7. omówiono szczegó(cid:228)y funkcji przetwarzania rozproszonego, która zapewnia organizowanie procesów biznesowych o wysokim stopniu rozproszenia bez potrzeby korzy- stania ze scentralizowanego przetwarzania lub mechanizmu regu(cid:228). Przep(cid:228)yw procesów w magistrali ESB mo(cid:276)e równie(cid:276) obejmowa(cid:232) specjalistyczne us(cid:228)ugi inte- gracji, które realizuj(cid:241) inteligentny routing komunikatów na podstawie tre(cid:264)ci. Skoro przep(cid:228)yw procesów opiera si(cid:246) na rozproszonej architekturze SOA, swoim zasi(cid:246)giem mo(cid:276)e tak(cid:276)e obj(cid:241)(cid:232) topologie wdra(cid:276)ania o wysokim stopniu rozproszenia (czasem rozdzielone oce- anami) bez konieczno(cid:264)ci radzenia sobie z granicami sieci fizycznych lub wieloma przeskokami protoko(cid:228)ów mi(cid:246)dzy aplikacjami i us(cid:228)ugami w magistrali (rysunek 1.4). Bezpiecze(cid:295)stwo i niezawodno(cid:316)(cid:235) Po(cid:228)(cid:241)czenia mi(cid:246)dzy w(cid:246)z(cid:228)ami w magistrali ESB obs(cid:228)uguj(cid:241) zapor(cid:246) firewall. Zabezpieczenia mi(cid:246)dzy aplikacjami i magistral(cid:241) ESB, a nawet mi(cid:246)dzy samymi jej w(cid:246)z(cid:228)ami umo(cid:276)liwiaj(cid:241) ustanowienie i utrzymanie najbardziej rygorystycznego uwierzytelniania, zarz(cid:241)dzanie danymi uwierzytel- niaj(cid:241)cymi i kontrol(cid:246) dost(cid:246)pu. W(cid:293)a(cid:316)ciwo(cid:316)ci magistrali ESB (cid:95) 31 Kup książkęPoleć książkę Rysunek 1.4. Organizowanie i przep(cid:228)yw procesów obejmuj(cid:241)ce swoim zasi(cid:246)giem topologie wdra(cid:276)ania o wysokim stopniu rozproszenia wyst(cid:246)puj(cid:241)cym mi(cid:246)dzy granicami sieci fizycznych i logicznych Niezawodno(cid:264)(cid:232) jest osi(cid:241)gana przez umieszczenie w rdzeniu magistrali ESB korporacyjnego opro- gramowania MOM, które zapewnia komunikacj(cid:246) asynchroniczn(cid:241), bezpieczne dostarczanie danych biznesowych i integralno(cid:264)(cid:232) transakcji. Jak si(cid:246) oka(cid:276)e w rozdziale 5., nie jest to tradycyjna technologia MOM sprzed dwóch dekad. Od tamtego czasu wymagania biznesowe zwi(cid:246)k- szy(cid:228)y si(cid:246) i ustabilizowa(cid:228)y. Oprogramowanie MOM w rdzeniu magistrali ESB musi by(cid:232) w stanie spe(cid:228)nia(cid:232) obecne wymogi. Autonomiczne, lecz stowarzyszone (cid:316)rodowisko Tradycyjne metody obowi(cid:241)zuj(cid:241)ce w brokerze EAI z konfiguracj(cid:241) gwia(cid:274)dzist(cid:241) s(cid:241) zwykle obar- czone problemami dotycz(cid:241)cymi granic organizacyjnych, czasami powodowanymi przez ograniczenia fizyczne brokera EAI, nieb(cid:246)d(cid:241)cego w stanie w prosty sposób obejmowa(cid:232) swoim zasi(cid:246)giem zapór firewall i domen sieciowych. Co wa(cid:276)niejsze, je(cid:264)li nawet architektura z konfi- guracj(cid:241) gwia(cid:274)dzist(cid:241) poradzi sobie z granicami organizacyjnymi, nadal nie umo(cid:276)liwi uzyskania lokalnej autonomii, która jest wymagana przez poszczególne jednostki biznesowe do dzia(cid:228)a- nia przy zachowaniu cz(cid:246)(cid:264)ciowej niezale(cid:276)no(cid:264)ci od siebie. Jednym z najwi(cid:246)kszych problemów towarzysz(cid:241)cych rozszerzaniu zasi(cid:246)gu integracji poza poziom dzia(cid:228)u jest zestawienie lokalnej autonomii ze scentralizowan(cid:241) kontrol(cid:241). W ramach kultury biznesowej obecnej w wi(cid:246)kszo(cid:264)ci du(cid:276)ych (cid:264)rodowisk korporacyjnych ka(cid:276)dy dzia(cid:228) lub ka(cid:276)da jednostka biznesowa wymaga dzia(cid:228)ania niezale(cid:276)nego od siebie. Niemniej jednak w dalszym ci(cid:241)gu zale(cid:276)ne s(cid:241) one od siebie w przypadku wspó(cid:228)u(cid:276)ytkowanych zasobów, a tak- (cid:276)e informacji zwi(cid:241)zanych z raportowaniem i ksi(cid:246)gowo(cid:264)ci(cid:241), które trafiaj(cid:241) do wspólnej funkcji biznesowej. W takim (cid:264)rodowisku nierozs(cid:241)dne by(cid:228)oby stosowanie strategii integracji, która wymaga przep(cid:228)y- wu ca(cid:228)ego ruchu zwi(cid:241)zanego z komunikatami przez centralny broker komunikatów, znajdu- 32 (cid:95) Rozdzia(cid:293) 1. Magistrala ESB — wprowadzenie Kup książkęPoleć książkę j(cid:241)cy si(cid:246) w centralach. Nie jest to jedynie przeszkoda natury technicznej, lecz tak(cid:276)e kwestia dotycz(cid:241)ca kultury korporacyjnej. W (cid:264)rodowisku lu(cid:274)no powi(cid:241)zanych jednostek biznesowych nie maj(cid:241) sensu takie rzeczy, jak np. zarz(cid:241)dzanie przez pojedyncz(cid:241), scentralizowan(cid:241) funkcj(cid:246) informatyczn(cid:241) korporacji przep(cid:228)ywem procesów biznesowych mi(cid:246)dzy lokalnymi aplikacjami lub domenami zabezpiecze(cid:254). Lu(cid:274)no powi(cid:241)zane jednostki biznesowe w organizacji wymagaj(cid:241) dzia(cid:228)ania niezale(cid:276)nie od siebie. Ka(cid:276)da z nich powinna mie(cid:232) w(cid:228)asn(cid:241) funkcj(cid:246) informatyczn(cid:241). Ponadto jednostki biznesowe nie mog(cid:241) by(cid:232) zmuszane do post(cid:246)powania z uwzgl(cid:246)dnieniem routingu ca(cid:228)ego ruchu sieciowego komunikatów lub delegowania kontroli swoich regu(cid:228) biz- nesowych i domen zabezpiecze(cid:254) za po(cid:264)rednictwem scentralizowanego brokera integracji znajduj(cid:241)cego si(cid:246) w tym lub innym miejscu (rysunek 1.5). Rysunek 1.5. Osobne jednostki biznesowe s(cid:241) pozbawione niezb(cid:246)dnej autonomii w przypadku korzystania ze scentralizowanego brokera integracji z konfiguracj(cid:241) gwia(cid:274)dzist(cid:241) Lokalne jednostki biznesowe i dzia(cid:228)y musz(cid:241) mie(cid:232) kontrol(cid:246) nad w(cid:228)asnymi, lokalnymi zasobami in- formatycznymi, takimi jak aplikacje dzia(cid:228)aj(cid:241)ce w ich siedzibie. Infrastruktura integracji po- winna wspiera(cid:232) topologie wdra(cid:276)ania w celu praktycznej obs(cid:228)ugi modelu biznesowego. Magistrala ESB zapewnia taki model wdra(cid:276)ania, zezwalaj(cid:241)c na lokalny ruch sieciowy komunikatów, a tak(cid:276)e na lokalne instalowanie, konfigurowanie i zabezpieczanie komponentów integracji i adapterów oraz zarz(cid:241)dzanie nimi. Jednocze(cid:264)nie nadal mo(cid:276)liwe jest pod(cid:228)(cid:241)czenie lokalnych domen inte- gracji do wi(cid:246)kszej stowarzyszonej sieci integracji ze zintegrowanym modelem zabezpiecze(cid:254) (rysunek 1.6). W(cid:228)a(cid:264)ciwo(cid:264)ci rozproszenia magistrali ESB s(cid:241) osi(cid:241)gane przez abstrakcj(cid:246) definicji punktów ko(cid:254)co- wych opart(cid:241) na szczegó(cid:228)ach wdro(cid:276)enia fizycznego i u(cid:276)ywanych protoko(cid:228)ach (cid:228)(cid:241)cz(cid:241)cych, a tak(cid:276)e przez organizacj(cid:246) i routing danych mi(cid:246)dzy tymi punktami. W(cid:228)a(cid:264)ciwo(cid:264)ci stowarzyszenia s(cid:241) uzyskiwane dzi(cid:246)ki mo(cid:276)liwo(cid:264)ci magistrali ESB polegaj(cid:241)cej na selektywnym przechodzeniu przez granice domen aplikacji i zabezpiecze(cid:254) oraz segregowaniu ich. W(cid:293)a(cid:316)ciwo(cid:316)ci magistrali ESB (cid:95) 33 Kup książkęPoleć książkę Rysunek 1.6. Autonomiczna i stowarzyszona magistrala ESB umo(cid:276)liwia organizacjom wspólne stowarzyszanie operacji z pomini(cid:246)ciem granic organizacyjnych Konfiguracja i zarz(cid:233)dzanie zdalne W niektórych modelach biznesowych nie ma sensu obecno(cid:264)(cid:232) lokalnego personelu informatyczne- go w ka(cid:276)dej zdalnej lokalizacji, cho(cid:232) nadal istnieje potrzeba istnienia lu(cid:274)no powi(cid:241)zanej, auto- nomicznej, ale te(cid:276) stowarzyszonej sieci integracji. Aby zilustrowa(cid:232) t(cid:246) kwesti(cid:246), przybli(cid:276)my prost(cid:241) analiz(cid:246) przyk(cid:228)adu dotycz(cid:241)cego wdra(cid:276)ania magistrali ESB w bran(cid:276)y handlu detalicznego. Sie(cid:232) wypo(cid:276)yczalni p(cid:228)yt wideo mo(cid:276)e si(cid:246) sk(cid:228)ada(cid:232) z setek lub tysi(cid:246)cy zdalnych jednostek, w których znajduje si(cid:246) ten sam zestaw aplikacji. Ponadto wszystkie jednostki dzia(cid:228)aj(cid:241) w ten sam sposób w odniesieniu do zarz(cid:241)dzania magazynem, ksi(cid:246)gowo(cid:264)ci i raportowania (rysunek 1.7). W przypadku korzystania z magistrali ESB mo(cid:276)liwe jest okre(cid:264)lenie planu integracji w celu ob- s(cid:228)ugi lokalnego komunikowania mi(cid:246)dzy aplikacjami w zdalnej jednostce handlowej. Obejmuje on definicje interfejsów aplikacji w jednostce, routing ruchu sieciowego komunikatów i zarz(cid:241)dza- nie kana(cid:228)ami komunikatów oraz uprawnienia zabezpiecze(cid:254). Plan mo(cid:276)e równie(cid:276) uwzgl(cid:246)dnia(cid:232) komponenty integracji, takie jak adapter aplikacji, adapter protoko(cid:228)u lub transformacja danych. Taki plan integracji lub szablon mo(cid:276)e zosta(cid:232) wdro(cid:276)ony i dostosowany w ka(cid:276)dej jednostce, a ponadto mo(cid:276)e by(cid:232) realizowany niezale(cid:276)nie od wszystkich innych jednostek (rysunek 1.8). Przedstawiony plan wdra(cid:276)ania zdalnego nie jest obecny tylko w handlu detalicznym. Plan ma te(cid:276) zastosowanie w innych bran(cid:276)ach. Ujednolicone zarz(cid:241)dzanie zdalne stowarzyszonymi domenami integracji to kluczowy element powodzenia dowolnego wdro(cid:276)enia magistrali ESB w (cid:264)rodowisku o wysokim stopniu rozproszenia. 34 (cid:95) Rozdzia(cid:293) 1. Magistrala ESB — wprowadzenie Kup książkęPoleć książkę Rysunek 1.7. Sie(cid:232) wypo(cid:276)yczalni p(cid:228)yt wideo z setkami lub tysi(cid:241)cami zdalnych jednostek, w których znajduje si(cid:246) ten sam zestaw aplikacji Rysunek 1.8. Plan konfiguracji magistrali ESB wdro(cid:276)ony w ka(cid:276)dej zdalnej jednostce oraz zdalnie konfigurowany i zarz(cid:241)dzany W(cid:293)a(cid:316)ciwo(cid:316)ci magistrali ESB (cid:95) 35 Kup książkęPoleć książkę BEZPIECZNE I NIEZAWODNE (cid:292)(cid:232)CZA PRZESY(cid:292)ANIA KOMUNIKATÓW Oprócz lokalnego wspó(cid:228)u(cid:276)ytkowania danych mi(cid:246)dzy aplikacjami we wszystkich zdalnych jed- nostkach handlowych, wymagaj(cid:241) one wymiany informacji z central(cid:241) na potrzeby ksi(cid:246)gowo(cid:264)ci i raportowania, zarz(cid:241)dzania kredytami i (cid:264)ledzenia danych pracowników. Zdalne jednostki han- dlowe mog(cid:241) równie(cid:276) wymaga(cid:232) wzajemnego wspó(cid:228)u(cid:276)ytkowania informacji. Na przyk(cid:228)ad du(cid:276)a sie(cid:232) wypo(cid:276)yczalni p(cid:228)yt wideo mo(cid:276)e wymaga(cid:232) oferowania us(cid:228)ugi, w przypadku której klient mo(cid:276)e wypo(cid:276)yczy(cid:232) p(cid:228)yt(cid:246) wideo w punkcie znajduj(cid:241)cym si(cid:246) w pobli(cid:276)u miejsca zamieszkania, a nast(cid:246)pnie zwróci(cid:232) j(cid:241) w innym punkcie, niedaleko miejsca pracy. Oznacza to, (cid:276)e w przypadku punktów handlowych w tym samym obszarze geograficznym niezb(cid:246)dna b(cid:246)dzie wymiana in- formacji o wypo(cid:276)yczonych p(cid:228)ytach w sposób zbli(cid:276)ony do wymiany danych w czasie rzeczywi- stym. Z powodu opó(cid:274)nienia i problemów z elastyczno(cid:264)ci(cid:241) sieci satelitarnych mi(cid:246)dzy zdalnymi jednostkami handlowymi i central(cid:241) zwyczajnie nie jest realne utrzymanie sta(cid:228)ego, centralne- go punktu dost(cid:246)pu do wszystkich informacji o wypo(cid:276)yczonych p(cid:228)ytach. Taka przej(cid:264)ciowa informacja o tym, co klient wypo(cid:276)yczy(cid:228) dwie godziny temu, wymaga wspó(cid:228)u(cid:276)ytkowania lub udost(cid:246)pnienia za pomoc(cid:241) zintegrowanego (cid:228)(cid:241)cza danych mi(cid:246)dzy zdalnymi jednostkami han- dlowymi. Ze wzgl(cid:246)du na to, (cid:276)e (cid:228)(cid:241)cze mi(cid:246)dzy central(cid:241) i zdalnymi jednostkami handlowymi jest uzyski- wane przy u(cid:276)yciu niezawodnego przesy(cid:228)ania komunikatów, przerwy wyst(cid:246)puj(cid:241)ce w us(cid:228)u- dze sieciowej z powodu zawodnych (cid:228)(cid:241)czy satelitarnych s(cid:241) kompensowane przez warstw(cid:246) przesy(cid:228)ania komunikatów. Godne uwagi jest tak(cid:276)e to, (cid:276)e jednostki handlowe maj(cid:241) mo(cid:276)liwo(cid:264)(cid:232) wzajemnego po(cid:228)(cid:241)czenia przy u(cid:276)yciu bezpiecznego i niezawodnego kana(cid:228)u przesy(cid:228)ania ko- munikatów za po(cid:264)rednictwem Internetu. J(cid:253)zyk XML w roli „macierzystego” typu danych magistrali ESB J(cid:246)zyk XML to idealny fundament na potrzeby reprezentowania danych przep(cid:228)ywaj(cid:241)cych mi(cid:246)dzy aplikacjami w magistrali ESB. Dane generowane i wykorzystywane przez ogromn(cid:241) liczb(cid:246) aplikacji mog(cid:241) istnie(cid:232) w postaci ró(cid:276)nych formatów i schematów tworzenia pakietów. Cho(cid:232) magistrala ESB z pewno(cid:264)ci(cid:241) ma mo(cid:276)liwo(cid:264)(cid:232) przekazywania danych za pomoc(cid:241) dowolnego wy- branego schematu tworzenia pakietów lub kopert, mnóstwo korzy(cid:264)ci przemawia za reprezento- waniem przesy(cid:228)anych danych w formacie XML. Jedn(cid:241) z tych korzy(cid:264)ci jest mo(cid:276)liwo(cid:264)(cid:232) u(cid:276)ycia specjalistycznych us(cid:228)ug magistrali ESB, które (cid:228)(cid:241)cz(cid:241) dane z ró(cid:276)nych (cid:274)róde(cid:228) w celu utworzenia nowych widoków danych, a tak(cid:276)e rozszerzania i ponownego okre(cid:264)lania miejsca docelowego komunikatów na potrzeby zaawansowanego wspó(cid:228)u(cid:276)ytkowania danych mi(cid:246)dzy aplikacjami. W rozdziale 4. zosta(cid:228)a obja(cid:264)niona zasadnicza zaleta formatu XML, czyli mo(cid:276)liwo(cid:264)(cid:232) wyelimi- nowania konieczno(cid:264)ci synchronizowania przez organizacj(cid:246) aktualizacji mi(cid:246)dzy aplikacjami. Dodatkowo bardziej szczegó(cid:228)owo przedstawiono tam filozofi(cid:246) przy(cid:264)wiecaj(cid:241)c(cid:241) rozproszonym us(cid:228)ugom transformacji XML. Przepustowo(cid:316)(cid:235) danych biznesowych w czasie rzeczywistym Magistrala ESB eliminuje problemy z opó(cid:274)nieniem, zapewniaj(cid:241)c przepustowo(cid:264)(cid:232) w czasie rze- czywistym w przypadku danych przesy(cid:228)anych mi(cid:246)dzy aplikacjami w obr(cid:246)bie magistrali. Gdy pisano ksi(cid:241)(cid:276)k(cid:246), jedn(cid:241) z najpopularniejszych metod integracji by(cid:228)o nocne przetwarzanie wsa- dowe. Strategie integracji z przetwarzaniem wsadowym wykonywanym noc(cid:241) lub o innych 36 (cid:95) Rozdzia(cid:293) 1. Magistrala ESB — wprowadzenie Kup książkęPoleć książkę porach s(cid:241) jednak podatne na du(cid:276)y margines b(cid:228)(cid:246)du, a ponadto mog(cid:241) powodowa(cid:232) opó(cid:274)nienia podczas uzyskiwania informacji. Pojawiaj(cid:241)ce si(cid:246) du(cid:276)e opó(cid:274)nienie towarzysz(cid:241)ce pobieraniu aktualnych informacji mo(cid:276)e by(cid:232) kosztowne. W rozdziale 9. zosta(cid:228)o to omówione bardziej szczegó(cid:228)owo. Poza tym obja(cid:264)niono, jak magistrala ESB mo(cid:276)e zosta(cid:232) wykorzystana do prze- prowadzenia w firmie refaktoryzacji w celu zast(cid:241)pienia nocnego przetwarzania wsadowego przesy(cid:228)aniem zmian danych biznesowych w czasie rzeczywistym. Rozpoznanie operacji Rozpoznanie operacji (ang. operational awareness) oznacza mo(cid:276)liwo(cid:264)(cid:232) uzyskania przez anali- tyka biznesowego wgl(cid:241)du w stan i kondycj(cid:246) operacji biznesowych. Infrastruktura pozwalaj(cid:241)ca na (cid:264)ledzenie i raportowanie w odpowiednim czasie danych przesy(cid:228)anych w obr(cid:246)bie organi- zacji w postaci komunikatów biznesowych procesu biznesowego stanowi bezcenne narz(cid:246)dzie, które u(cid:228)atwia zapewnienie rozpoznania operacji. Pojawi(cid:228)a si(cid:246) osobna kategoria produktów, identyfikowanych przez termin BAM (Business Activity Monitoring), które maj(cid:241) za zadanie wyeliminowanie wielu problemów zwi(cid:241)zanych z rozpoznaniem operacji. Jedn(cid:241) z korzy(cid:264)ci wynikaj(cid:241)cych z u(cid:276)ycia XML jako macierzystego formatu d
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

ESB. Magistrala usług korporacyjnych
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: