Artykuł ma dwie czę­ści. Pierwsza część jest adre­so­wa­na do kadr zarząd­czych, cały arty­kuł (obie czę­ści) do osób zaj­mu­ją­cych się pro­jek­to­wa­niem rozwiązań.

Wstęp

Mamy ogól­no­świa­to­wą sieć Internet, apli­ka­cje lokal­ne i w chmu­rze, apli­ka­cje naszych kon­tra­hen­tów i apli­ka­cje cen­tral­nych urzę­dów. Wszystkie one współ­pra­cu­ją i wymie­nia­ją dane, czy­li są zin­te­gro­wa­ne. Dlatego inte­gra­cja sta­ła się cechą każ­de­go sys­te­mu informatycznego. 

Wyjątkowo na począt­ku (poni­żej) umiesz­czam cały ten cie­ka­wy refe­rat, moż­na bo pomi­nąć i czy­tać dalej, jed­nak jeże­li ktoś chce poznać prze­wi­dy­wa­nia z roku 2016 i ma czas, pole­cam (teraz lub później):

The Future of Software Engineering ? Mary Poppendieck ? GOTO 2016

Obecnie klu­czo­wym pyta­niem jest: Jak zin­te­gro­wać, a nie: Czy zintegrować. 

Pogodzenie się z tym, że świat sys­te­mó ERP już nigdy nie będzie tak pro­sty jak w cza­sach main­fra­me­’ów, czy­li jed­nej cen­tral­nej apli­ka­cji, jest nieuniknione. 

Czym jest obec­nie inte­gra­cja? To wymia­na danych a nie ich współ­dzie­le­nie: dane z urzę­dem wymie­nia­my, dane z kon­tra­hen­tem wymie­nia­my, nie współ­dzie­li­my żad­nych danych z tymi pod­mio­ta­mi, każ­dy ma swo­je wła­sne, bez­piecz­ne bazy danych, i to wszyst­ko ład­nie dzia­ła! Idea zbu­do­wa­nia wszyst­kich funk­cjo­nal­no­ści jako zin­te­gro­wa­nej apli­ka­cji na jed­nej współ­dzie­lo­nej bazie danych w cza­sach obec­nych jest uto­pią. Taką samą jak hipo­te­tycz­na cen­tral­na baza danych dla wszyst­kich skle­pów inter­ne­to­wych, firm kurier­skich i ban­ków, a one są jed­nak zin­te­gro­wa­ne: one wymie­nia­ją dane a nie współdzielą!

ERP to (ang.) Enterprise Resource Planning czy­li Planowanie Zasobów Przedsiębiorstwa. To sys­tem wyko­rzy­sty­wa­ny przez fir­my do zarzą­dza­nia i inte­gro­wa­nia waż­nych ele­men­tów ich dzia­łal­no­ści. Ale kto powie­dział, że to ma być mono­lit od jed­ne­go producenta? 

Nadal spo­ty­kam pejo­ra­tyw­ne okre­śle­nia sys­tem poin­te­gro­wa­ny” jako kry­ty­kę budo­wy sys­te­mu ERP z kom­po­nen­tów i inte­gra­cji jako wymia­ny danych. Autor tego okre­śle­nia naj­praw­do­po­dob­niej nadal żyje w świe­cie mainframe. 

Chociaż dostaw­cy sys­te­mów ERP ofe­ru­ją apli­ka­cje dla przed­się­biorstw i twier­dzą, że ich zin­te­gro­wa­ny sys­tem jest naj­lep­szym roz­wią­za­niem, wszyst­kie modu­ły w jed­nym sys­te­mie ERP rzad­ko kie­dy są naj­lep­sze z najlepszych.

https://​www​.gart​ner​.com/​e​n​/​i​n​f​o​r​m​a​t​i​o​n​-​t​e​c​h​n​o​l​o​g​y​/​g​l​o​s​s​a​r​y​/​b​e​s​t​-​o​f​-​b​r​eed

Integracja tak, ale czy to ma być jedna wspólna baza danych? 

Po pierw­sze dane mają róż­ne kon­tek­sty, a ich zna­cze­nie zale­ży od kon­kret­ne­go kon­tek­stu i miej­sca użycia: 

Model danych (UML) i ekran aplikacji. 

Powyżej zobra­zo­wa­no dane i ich kon­tekst. Data może być datą uro­dzin lub datą śmier­ci i nadal jest to data. Osoba może być oby­wa­te­lem w pań­stwo­wym reje­strze, ale może być pra­cow­ni­kiem, klien­tem itp.. Opis oso­by (struk­tu­ra danych) nie zmie­nia się mimo zmia­ny jej roli. W reje­strze oby­wa­te­li data, jako pole (powy­żej), nawet taka sama, może tu wystę­po­wać wie­lo­krot­nie (tego same­go dnia może się wyda­rzyć nie­za­leż­nie wie­le róż­nych rze­czy). Jednak ta sama data, jako war­tość w reje­strze będą­cym kalen­da­rzem, musi być uni­kal­na: tu wystę­pu­je tyl­ko jeden raz. Czyli kalen­darz i rejestr np. aktów uro­dze­nia nie może być jed­na bazą”. 

Jak widać powyż­szej, to doku­ment i struk­tu­ra doku­men­tu, nada­je kon­tekst danym prze­cho­wy­wa­nym w polach (doku­ment, jego sek­cja). Takiej struk­tu­ry, natu­ral­nej z per­spek­ty­wy języ­ko­wej i biz­ne­so­wej, nie da się mapo­wać na, pozba­wio­ny redun­dan­cji, model rela­cyj­nej bazy danych. Zapisanie tego doku­men­tu w mode­lu rela­cyj­nym typo­we­go ERP wyma­ga stwo­rze­nia dodat­ko­wych tablic, a odtwo­rze­nie z nich doku­men­tu wyma­ga skom­pli­ko­wa­ne­go zapy­ta­nia SQL do tej bazy (nie w niej doku­men­tów a jedy­nie dane). W bazach rela­cyj­nych NIE MA żad­nych doku­men­tów, są wycią­gnię­te z nich, i pozba­wio­ne kon­tek­stu, dane. Ich zapis i pobra­nie wyma­ga skom­pli­ko­wa­nych (czy­taj kosz­tow­nych w utwo­rze­niu i kon­ser­wa­cji) zapy­tań SQL. 

Powyższy doku­ment, bez żad­ne­go pro­ble­mu: bez utra­ty kon­tek­stu i bez mno­że­nia typów dat, zapi­sze­my jako kom­plet­ny for­mu­larz, np. w for­ma­cie XML w doku­men­to­wej bazie danych .

Wspólna baza danych jest z zasa­dy jed­no­kon­tek­sto­wa, więc pew­nych infor­ma­cji, jako nie­za­leż­nych infor­ma­cji, po pro­stu nie da się tak prze­twa­rzać. To dla­te­go prak­tycz­nie nie jest moż­li­we zbu­do­wa­nie jed­ne­go uni­wer­sal­ne­go sys­te­mu ERP z jed­ną cen­tral­ną rela­cyj­ną bazą danych, ale moż­li­we jest łatwe zbu­do­wa­nie dowol­ne­go sys­te­mu w posta­ci kil­ku zin­te­gro­wa­nych, dzie­dzi­no­wych kom­po­nen­tów. Problem ten opi­sał i wyja­śnił w 2014 roku M.Fowler:

Dlaczego nie da się na jed­nej wspól­nej bazie danych zbu­do­wać apli­ka­cji zarzą­dza­ją­cej sprze­da­żą i obsłu­gą wspar­cia posprze­da­żo­we­go; jak zależ­ne od kon­tek­stu jest zna­cze­nie danych źr.: .

Sales Context” oraz Support Context” to dwa róż­ne kon­tek­sty prze­twa­rza­nia tych samych danych: Customer i Product w kon­tek­ście sys­te­mu sprze­da­ży (np. CRM) to uni­kal­ne, czę­sto aktu­ali­zo­wa­ne, zapi­sy w bazie tego kom­po­nen­tu. Jednak w kon­tek­ście zgło­szeń ser­wi­so­wych są to wyłącz­nie atry­bu­ty Zgłoszeń ser­wi­so­wych, jako fak­ty histo­rycz­ne, są nie­zmie­nial­ne w przy­szło­ści. Zbudowanie takie­go sys­te­mu w posta­ci dwóch odręb­nych i zin­te­gro­wa­nych kom­po­nen­tów będzie pro­ste. Zbudowanie go w opar­ciu o jed­ną współ­dzie­lo­ną, rela­cyj­ną bazę danych, będzie bar­dzo kosz­tow­nym wyzwa­niem, a w przy­szło­ści nie będzie­my mogli tych obsza­rów oddzie­lić od sie­bie, np. gdy fir­ma podzie­li sie na dwie spe­cja­li­zo­wa­ne spół­ki (co jest dość czę­sto obecnie).

Bardzo duża wadą sys­te­mów trans­ak­cyj­nych, budo­wa­nych na jed­nej cen­tral­nej bazie rela­cyj­nej, jest ich male­ją­ca wydaj­ność ze wzro­stem licz­by użyt­kow­ni­ków i ilo­ści zapi­sa­nych danych. Wady tej nie mają sys­te­my kom­po­nen­to­we i sys­te­mu budo­wa­ne na doku­men­to­wych bazach danych typu NoSQL (patrz dla­cze­go).

Referencyjny model procesów biznesowych

Czasy mono­li­tów się skoń­czy­ły, i nawet jeże­li pla­no­wa­ne jest wdro­że­nie jed­ne­go ERP”, już nigdy nie będzie to jedy­na apli­ka­cja w fir­mie. Coraz czę­ściej zakres wdro­że­nia mono­li­tycz­ne­go sys­te­mu ERP ogra­ni­cza się do obsza­ru nazy­wa­ne­go back-offi­ce” czy­li do księ­go­wo­ści i admi­ni­stra­cji (pro­ce­sów wspie­ra­ją­cych). W 1985 roku M.E.Porter (rok 1985 to pierw­sze wyda­nie Strategii Konkurencji ) opi­sał tak zwa­ny wewnętrz­ny łań­cuch war­to­ści fir­my. Graficznie zobra­zo­wał go tak:

Łańcuch wartości M.E.Porter
Wewnętrzny łań­cuch war­to­ści M.E.Porter’a

Powyższy dia­gram nadal sta­no­wi kla­sy­kę pro­ce­so­we­go podej­ścia do zarzą­dza­nia i struk­tu­ry gru­po­wa­nia pro­ce­sów biz­ne­so­wych (patrz Cambridge). Jest to stan­dar­do­wy, bazo­wy szkie­let mode­lo­wa­nia pro­ce­sów biz­ne­so­wych wewnątrz orga­ni­za­cji (star­ting point). Procesy biz­ne­so­we (czy­li tak­że aktyw­no­ści jako ich wewnętrz­na część) zosta­ły tu podzie­lo­ne na dwie pod­sta­wo­we gru­py: wspie­ra­ją­ce (suport acti­vi­ties) i ope­ra­cyj­ne (pri­ma­ry acti­vi­ties, core). 

Pomiędzy gru­pą pro­ce­sów wspie­ra­ją­cych i ope­ra­cyj­nych jest zasad­ni­cza róż­ni­ca: zmien­ność i zależ­ność od pra­wa i stan­dar­dów. Procesy wspie­ra­ją­ce są w znacz­nej mie­rze regu­lo­wa­ne pra­wem, sta­no­wią stan­dar­dy zarzą­dza­nia, nor­my pro­ce­du­ral­ne (nor­my ISO itp.). Ten obszar nie budu­je prze­wa­gi ryn­ko­wej, tu mar­ża powsta­je jako wewnętrz­na spraw­ność (obni­ża­nie kosztów). 

Procesy ope­ra­cyj­ne (core) to klu­czo­wy łań­cuch budo­wy mar­ży. To tu powsta­je prze­wa­ga ryn­ko­wa: jakość pro­duk­tów i usług. To tu są wdra­ża­ne stan­dar­dy bran­żo­we. Tu jest wła­śnie dzi­siej­sza gra­ni­ca mię­dzy ERP (pro­ce­sy wspie­ra­ją­ce, zaso­by), a apli­ka­cja­mi dzie­dzi­no­wy­mi (WMS, MES, APS, WorkFlow, e‑Commerce i wie­le innych). Próba uczy­nie­nia z nich wszyst­kich modu­łów jed­ne­go sys­te­mu, współ­dzie­lą­ce­go dane w jed­nej bazie danych, jest prak­tycz­nie awy­ko­nal­na (patrz powyż­sze M.Fowler). Tym bar­dziej, że czę­sto­tli­wość zmian w każ­dym obsza­rze jest inna, a dzie­dzi­no­we sys­te­my np. wspo­ma­ga­nia pro­duk­cji to zupeł­nie inny obszar spe­cja­li­za­cji niż np. księ­go­wość czy kadry (to dla­te­go zupeł­nie inne fir­my spe­cja­li­zu­jąc się w dostar­cza­niu opro­gra­mo­wa­nia dla tych dziedzin). 

Właśnie głów­nym powo­dem tego podzia­łu, i tego że linia tego podzia­łu jest mię­dzy admi­ni­stra­cją a dzia­łal­no­ścią ope­ra­cyj­ną, jest zmien­ność. Gdyby porów­nać mię­dzy sobą fir­my z róż­nych branż, to oka­że się, że obszar pro­ce­sów wspie­ra­ją­cych to sta­bil­ny obszar admi­ni­stra­cji, gdzie rota­cja kadr jest mała, a ewen­tu­al­na zmia­na miej­sca pra­cy nie zale­ży od bran­ży i nie wyma­ga przekwalifikowania. 

Obszar ope­ra­cyj­ny to dedy­ko­wa­ne dzie­dzi­no­we dzia­ła­nia, nace­cho­wa­ne spe­cy­fi­ką kon­kret­nej bran­ży i spe­cja­li­sta­mi z dzie­dzi­ny…”. To dla­te­go na ryn­ku jest tak wie­le dzie­dzi­no­wych apli­ka­cji, któ­re powsta­ły do zarzą­dza­nia spe­cy­fi­ką okre­ślo­nych dzia­łań w okre­ślo­nej bran­ży. Nie przy­pad­kiem nazy­wa­my te apli­ka­cje sys­te­ma­mi branżowymi”. 

Firma pro­duk­cyj­na to z regu­ły naj­bar­dziej skom­pli­ko­wa­ny mecha­nizm, sys­tem ERP sta­no­wi tu jedy­nie czu­bek całe­go systemu:

W efek­cie, dzi­siej­sza spraw­na fir­ma (orga­ni­za­cja) będzie mia­ła stan­dar­do­wy ERP” wdro­żo­ny w obsza­rze pro­ce­sów wspie­ra­ją­cych, oraz – zin­te­gro­wa­ny z nim – zestaw dedy­ko­wa­nych, bran­żo­wych aplikacji.

Integracja jako wymaganie

Ta część jest adre­so­wa­na do każ­de­go kto mode­lu­je inte­gra­cje sys­te­mów IT (lub chce się tego nauczyć). 

W 2014 arty­kuł o inte­gra­cji koń­czy­łem słowami: 

Dedykowane dzie­dzi­no­we apli­ka­cje coraz czę­ściej są wdra­ża­ne eta­pa­mi zamiast jed­ne­go duże­go ERP. Taka inte­gra­cja nie jest wbrew pozo­rom kosz­tow­na, kosz­tow­ny jest brak sto­so­wa­nia dobrych prak­tyk i wzor­ców, któ­re war­to poznać. Zwinność dzia­ła­nia dzi­siej­szych firm na ryn­ku to wymóg a nie opcja. Zwinność taka to nie jeden duży ERP (mono­pol jed­ne­go usłu­go­daw­cy), to kil­ka zin­te­gro­wa­nych, dedy­ko­wa­nych nie­za­leż­nych apli­ka­cji , wdra­ża­nych bez kasto­mi­za­cji (wybie­ra­my naj­lep­szy pro­dukt w danym momen­cie). Ich (apli­ka­cje dzie­dzi­no­we) wymia­na na inne, przy dobrze wyko­na­nej inte­gra­cji, to jest pro­ces, któ­ry nie gene­ru­je mon­stru­al­nych kosz­tów każ­do­ra­zo­wej ana­li­zy i prze­rób­ki cało­ści IT (kolej­nej kasto­mi­za­cji jed­ne­go ERP) w firmie.

(źr.: Wymagania poza­funk­cjo­nal­ne – inte­gra­cja – Jarosław Żeliński IT-Consulting)

Modelowanie inte­gra­cji opi­sy­wa­łem nie raz (patrz wyżej cyto­wa­ny arty­kuł): nale­ży udo­ku­men­to­wać archi­tek­tu­rę (kom­po­nen­ty i ich powią­za­nia), doku­men­ty ope­ra­cyj­ne (jako agre­ga­ty danych), oraz sce­na­riu­sze opi­su­ją­ce meto­dy osią­ga­nia ocze­ki­wa­ne­go efek­tu. Scenariusze doku­men­tu­je­my dia­gra­ma­mi sekwen­cji, a zale­ca­ne para­me­try wywo­łań to wła­śnie ww. agre­ga­ty repre­zen­tu­ją­ce doku­men­ty (imple­men­to­wa­ne jako JSON lub XML). Taka postać mode­li jest dosko­na­ła do testów inte­gral­no­ści, jed­nak bar­dzo czę­sto poja­wia się potrze­ba prze­ka­za­nia w spe­cy­fi­ka­cji wyma­gań jed­ne­go określ­ne­go API, jako wydzie­lo­nej per­spek­ty­wy, i tu przy­cho­dzi z pomo­cą moż­li­wość stwo­rze­nia dedy­ko­wa­ne­go dia­gra­mu klas, któ­re­go celem jest udo­ku­men­to­wa­nie wyłącz­nie okre­ślo­ne­go API (np. wyma­ga­ne­go lub usta­lo­ne­go w toku wdrożenia). 

Trochę technologii czyli REST API

Przenoszenie Reprezentacji Stanu” (ang. Representational sta­te trans­fer: REST) jest meto­dą komu­ni­ka­cji, któ­ra defi­niu­je zestaw wyma­gań przy two­rze­niu usług sie­cio­wych. Usługi sie­cio­we, któ­re są zgod­ne z REST, zwa­ne tak­że usłu­ga­mi sie­cio­wy­mi RESTful Web Services (RWS), zapew­nia­ją inte­ro­pe­ra­cyj­ność mię­dzy sys­te­ma­mi kom­pu­te­ro­wy­mi, tak sie­ci Internet jak i wewnątrz sie­ci jed­nej orga­ni­za­cji. Usługi RWS umoż­li­wia­ją sys­te­mom (inte­gro­wa­nym apli­ka­cjom) wza­jem­ny dostęp do danych w for­mie tek­sto­wej i mani­pu­la­cję nimi, za pomo­cą jed­no­li­te­go i pre­de­fi­nio­wa­ne­go zesta­wu bez­sta­no­wych ope­ra­cji. Całość nazy­wa­my sty­lem budo­wy archi­tek­tu­ry, jest on w peł­ni zgod­ny z obiek­to­wym i kom­po­nen­to­wym, zorien­to­wa­nym na inter­fej­sy, podej­ściem do pro­jek­to­wa­nia sys­te­mów, a klu­czo­wą zasa­dą jest tu her­me­ty­za­cja i wąska odpo­wie­dzial­ność kom­po­nen­tów. Podstawowe wzor­ce archi­tek­to­nicz­ne wyko­rzy­sty­wa­ne przy pro­jek­to­wa­niu inte­gra­cji to Saga, Łańcuch odpo­wie­dzial­no­ści i Repozytorium.

Dzięki bez­sta­no­we­mu pro­to­ko­ło­wi i stan­dar­do­wym ope­ra­cjom, sys­te­my budo­wa­ne w opar­ciu o RWS uzy­sku­ją dużą wydaj­ność, nie­za­wod­ność i moż­li­wość roz­wo­ju poprzez ponow­ne wyko­rzy­sta­nie kom­po­nen­tów (her­me­ty­za­cja), któ­re mogą być zarzą­dza­ne i aktu­ali­zo­wa­ne bez wpły­wu na sys­tem jako całość, nawet pod­czas jego działania.

Ograniczenia architektoniczne czyli wymagania wobec architektury

REST defi­niu­je 6 wyma­gań (to jego głów­ne cechy) architektonicznych.

1. Architektura usługobiorca-usługodawca

Zasadą sto­ją­cą za ogra­ni­cze­nia­mi usłu­go­bior­ca-usłu­go­daw­ca (inne spo­ty­ka­ne nazwy to: klient usłu­gi i usłu­go­daw­ca, klient-ser­wer, client – servi­ce pro­vi­der), jest sepa­ra­cja kon­tek­stów. Oddzielenie zadań zwią­za­nych z inter­fej­sem użyt­kow­ni­ka od zadań zwią­za­nych z logi­ką biz­ne­so­wą i prze­cho­wy­wa­niem danych popra­wia prze­no­śność inter­fej­sów użyt­kow­ni­ka na wie­lu plat­for­mach. Poprawia to rów­nież ska­lo­wal­ność poprzez uprosz­cze­nie kom­po­nen­tów (kil­ka pro­stych zamiast jed­ne­go zło­żo­ne­go). Być może naj­bar­dziej zna­czą­ce dla sie­ci Internet (i dla sie­ci w ogó­le) jest jed­nak to, że sepa­ra­cja ta (her­me­ty­za­cja) pozwa­la kom­po­nen­tom roz­wi­jać się nie­za­leż­nie, bez wpły­wu na pozo­sta­łe, pozwa­la­jąc w ten spo­sób na ist­nie­nie róż­no­rod­no­ści tak w sie­ci Internet, jak i w sie­ci lokal­nej orga­ni­za­cji, pozwa­la na współ­ist­nie­nie wie­lu róż­nych i nie­za­leż­nych domen i zaso­bów. Hermetyzacja to tak­że nie­za­leż­ność od typów danych: prze­ka­zy­wa­ne dane to wyłącz­nie cią­gi zna­ków (string), ich typy muszą być uzgod­nio­ne po obu stro­nach (JSON) lub zde­fi­nio­wa­ne (XSD/XML) i mogą być ina­czej zde­fi­nio­wa­ne w każ­dym z pod­sys­te­mów (np. w jed­nym sys­te­mie będzie to np. typ date” w bazie rela­cyj­nej, a w innym ciąg zna­ków i maska walidacji). 

2. Bezstanowość

Komunikacja usłu­go­bior­ca-usłu­go­daw­ca jest ogra­ni­czo­na tym, że żaden kon­tekst usłu­go­bior­cy nie jest prze­cho­wy­wa­ny u usłu­go­daw­cy pomię­dzy żąda­nia­mi. Każde żąda­nie od dowol­ne­go usłu­go­bior­cy zawie­ra wszyst­kie infor­ma­cje nie­zbęd­ne do obsłu­że­nia żąda­nia. Stan sesji jest prze­cho­wy­wa­ny zawsze po stro­nie usłu­go­bior­cy (patrz wzo­rzec pro­jek­to­wy Saga). Stan sesji może być prze­ka­za­ny przez usłu­go­daw­cę do innej usłu­gi, takiej jak baza danych, aby utrzy­mać trwa­ły stan przez pewien czas i umoż­li­wić uwie­rzy­tel­nie­nie, ale wte­dy sta­no­wi on (stan jako nazwa) takie same dane jak pozo­sta­łe prze­ka­za­ne. Usługobiorca zaczy­na wysy­łać żąda­nia, gdy jest goto­wy do przej­ścia do kolej­ne­go kro­ku (nowe­go sta­nu). Reprezentacja każ­de­go sta­nu apli­ka­cji zawie­ra odno­śni­ki, któ­re mogą być uży­te następ­nym razem, gdy klient zde­cy­du­je się zaini­cjo­wać przej­ście do takie­go stanu. 

Kluczową cechą tej archi­tek­tu­ry jest tak­że to, że usłu­go­daw­ca (ser­wer) nigdy sam nie wywo­łu­je usłu­go­bior­cy (klient)!

3. Zdolność bufo­ro­wa­nia (cache)

Podobnie jak w sie­ci WWW, usłu­go­bior­ca i pośred­ni­cy mogą bufo­ro­wać odpo­wie­dzi. Odpowiedzi muszą zatem, w spo­sób ukry­ty lub jaw­ny, okre­ślać się (być ozna­czo­ne) jako bufo­ro­wal­ne lub nie, aby zapo­biec otrzy­my­wa­niu przez usłu­go­bior­cę nie­ak­tu­al­nych lub nie­po­praw­nych danych w odpo­wie­dzi na kolej­ne żąda­nia. Dobrze zarzą­dza­ne bufo­ro­wa­nie czę­ścio­wo lub cał­ko­wi­cie eli­mi­nu­je nie­któ­re inte­rak­cje usłu­go­bior­ca-usłu­go­daw­ca, dodat­ko­wo popra­wia­jąc ska­lo­wal­ność i wydajność.

4. Warstwy pośrednie

Usługobiorca zazwy­czaj nie może stwier­dzić, czy jest połą­czo­ny bez­po­śred­nio z ser­we­rem koń­co­wym, czy z pośred­ni­kiem po dro­dze. Oznacza to, że usłu­go­bior­ca nie wie, czy roz­ma­wia z pośred­ni­kiem (sys­tem pośred­ni­czą­cy, np. pro­xy), czy z wła­ści­wym usłu­go­daw­cą (patrz wzo­rzec archi­tek­to­nicz­ny Łańcuch odpo­wie­dzial­no­ści). Jeśli więc pomię­dzy usłu­go­bior­cą a usłu­go­daw­cą zosta­nie umiesz­czo­ne pro­xy lub load balan­cer, nie będzie to mia­ło wpły­wu na komu­ni­ka­cję i nie będzie koniecz­no­ści aktu­ali­zo­wa­nia kodu usłu­go­bior­cy lub usłu­go­daw­cy. Serwery (usłu­gi) pośred­ni­czą­ce mogą popra­wić ska­lo­wal­ność sys­te­mu poprzez umoż­li­wie­nie rów­no­wa­że­nia obcią­że­nia i zapew­nie­nie współ­dzie­lo­nych pamię­ci pod­ręcz­nych. Ponadto, bez­pie­czeń­stwo może być doda­ne jako dodat­ko­wa war­stwa pośred­nia dla usług sie­cio­wych, by wyraź­nie oddzie­lić logi­kę biz­ne­so­wą od logi­ki (reguł) bez­pie­czeń­stwa. Np. wydzie­le­nie war­stwy kon­tro­li dostę­pu do danych, wymu­sza np. wdra­ża­nie poli­ty­ki bez­pie­czeń­stwa (patrz wzo­rzec archi­tek­to­nicz­ny Repozytorium). Wreszcie, ozna­cza to rów­nież, że usłu­go­daw­ca (ser­wer) tak­że może wywo­ły­wać wie­le innych ser­we­rów w celu wyge­ne­ro­wa­nia odpo­wie­dzi dla usłu­go­bior­cy (klien­ta).

5. Kod na żąda­nie (opcjo­nal­nie)

Serwery usłu­go­daw­cy mogą tym­cza­so­wo roz­sze­rzać lub dosto­so­wy­wać funk­cjo­nal­ność usłu­go­bior­cy (klien­ta), prze­sy­ła­jąc mu zwrot­nie kod wyko­ny­wal­ny: na przy­kład skom­pi­lo­wa­ne kom­po­nen­ty, takie jak aple­ty Java, lub skryp­ty po stro­nie prze­glą­dar­ki WWW, takie jak JavaScript (to doty­czy apli­ka­cji inter­ne­to­wych dzia­ła­ją­cych w prze­glą­dar­ce WWW, a nie inte­gra­cji sys­te­mów, przy­kład w dal­szej części). 

6. Jednolity interfejs

Jednolity inter­fejs defi­niu­je komu­ni­ka­cję pomię­dzy usłu­go­bior­cą i usłu­go­daw­cą. Gdy pro­gra­mi­sta zapo­zna się z jed­nym ze zde­fi­nio­wa­nych inter­fej­sów API, powi­nien być w sta­nie zasto­so­wać podob­ne podej­ście do innych inter­fej­sów API, któ­re musi wykonać.

Polecenia HTTP REST

W REST infor­ma­cje po stro­nie ser­we­ra są trak­to­wa­ne jako zasób, do któ­re­go mozna uzy­skać dostęp w jed­no­li­ty spo­sób za pomo­cą URI (Uniform Resource Identifiers) i pro­to­ko­łu HTTP. Metody GET, POST, PUT i DELETE są stan­dar­do­wo uży­wa­ne w archi­tek­tu­rze inte­gra­cji opar­tej na REST. Poniższy sche­mat zawie­ra obja­śnie­nie tych metod:

REST and HTTP
Mapowanie typo­wych ope­ra­cji CRUD, na meto­dy REST/HTTP.

Warto wie­dzieć, że zamiast PUT moż­na użyć PATCH, jest to uprosz­cze­nie aktu­ali­zu­ją­ce wyłącz­nie zmie­nio­ne atry­bu­ty obiek­tu, wię­cej tu: REST API ? POST vs PUT vs PATCH.

Jak to działa w sieci?

REST pozwa­la tak­że na obsłu­gę żąda­nia dostę­pu do zaso­bów inter­ne­to­wych i mani­pu­lo­wa­nia nimi przy uży­ciu jed­no­li­te­go i pre­de­fi­nio­wa­ne­go zesta­wu reguł. Interakcja w sys­te­mach inter­ne­to­wych opar­tych na REST odby­wa się poprzez inter­ne­to­wy pro­to­kół HTTP (Hypertext Transfer Protocol). Na sys­tem Restful skła­da­ją się:

  • Żądający zaso­bów (obsłu­gi) klient (usłu­go­bior­ca).
  • Posiadający te zaso­by i udo­stęp­nia­ją­cy je ser­wer.

Np.:

REST protocol
Typowa archi­tek­tu­ra w sie­ci Internet: Przeglądarka Internetowa – ser­wer WWW.

Więcej:

Modelowanie REST API

Standardowa konstrukcja UML

W UML inter­fejs to na dia­gra­mie klas UML kla­sa ozna­czo­na ste­reo­ty­pem «inter­fejs», ope­ra­cje tej kla­sy to ope­ra­cje tego inter­fej­su. Na dia­gra­mie kom­po­nen­tów kla­sa inter­fej­su jest repre­zen­to­wa­na tyl­ko jako nazwa i zobra­zo­wa­na sym­bo­lem zwa­nym lizak” i kie­li­szek”, poka­za­no to poniżej: 

Modelowanie inter­fej­sów na dia­gra­mie kom­po­nen­tów UML i ich spe­cy­fi­ko­wa­nie na dia­gra­mie klas.

Na powyż­szym dia­gra­mie poka­za­no dwa kom­po­nen­ty: Klient (żąda usług) i Serwer (świad­czy usłu­gi). Przepływ danych może być w dwie stro­ny: pole­ce­nie get do Klienta oraz pole­ce­nia cre­ate i upda­te do ser­we­ra, jed­nak ini­cjo­wa­ne są one z zasa­dy przez kom­po­nent Klient (usłu­go­bior­ca wywo­łu­je ope­ra­cje usłu­go­daw­cy). Konstrukcja z liza­kiem jest sto­so­wa­na na Diagramie Komponentów. Na dia­gra­mie klas inter­fejs REST_API poka­że się (zosta­nie zobra­zo­wa­ny) jako kla­sa o ste­reo­ty­pie «inter­fa­ce».

W repo­zy­to­rium mode­lu lizak” REST-API oraz kla­sa REST_API to ten sam ele­ment. W rze­czy­wi­sto­ści są to np. trzy diagramy:

Formalny model: trzy dia­gra­my i odpo­wia­da­ją­ca im struk­tu­ra repo­zy­to­rium pro­jek­tu UML. Wszystkie trzy kon­struk­cje poka­za­ne na dia­gra­mie kom­po­nen­tów (Component Diagram) poka­zu­ją to samo i są popraw­ne, jed­nak naj­czę­ściej sto­so­wa­na jest pierwsza.

Diagram inte­rak­cji UML poka­zu­je wywo­ła­nia ope­ra­cji inter­fej­su REST_API (przy­po­mi­nam, że linie życia na dia­gra­mie inte­rak­cji repre­zen­tu­ją obiek­ty klas a nie klasy). 

Aby opi­sać por­ty sto­su­je­my Diagram Struktur Złożonych UML (Composite Structure Diagram), komponent/klasyfikator z por­ta­mi WE i WY:

Diagram Struktur Złożonych nota­cji UML

Modelowanie REST API z pomocą Visual Paradigm

Niektóre narzę­dzia CASE pozwa­la­ją na wyko­na­nie dedy­ko­wa­nej doku­men­ta­cji API, w spo­sób pozwa­la­ją­cy tak­że, w razie takiej potrze­by, na wyge­ne­ro­wa­nie szkie­le­tu kodu i jego dokumentacji. 

Producent narzę­dzia CASE Visual Paradigm dostar­cza powyż­szą kon­struk­cję jako pre­de­fi­nio­wa­ną kla­sę: dodat­ko­wy ste­reo­typ zasób REST”, nada­jąc mu dedy­ko­wa­ny sym­bol (pro­fil REST). Tak to opi­su­je pro­du­cent na swo­jej stronie:

Wywołanie API jest pod­sta­wo­wym ele­men­tem usłu­gi sie­cio­wej, i powin­no być zgod­ne z REST. Jest to obiekt zawie­ra­ją­cy URI, meto­dę żąda­nia http, powią­za­ne para­me­try oraz spe­cy­fi­ka­cję żądania/odpowiedzi. Każdy z zaso­bów REST repre­zen­tu­je kon­kret­ną usłu­gę dostęp­ną na ścież­ce okre­ślo­nej przez jego wła­ści­wość URI. Dlatego, jeśli chcesz mode­lo­wać wie­le usług, nale­ży nary­so­wać wie­le zaso­bów REST. (źr.:: How to design REST API – Visual Paradigm)

Z per­spek­ty­wy mode­lo­wa­nia jest to nadal stan­dar­do­wy dia­gram klas UML, jedy­nym dodat­kiem jest spe­cja­li­zo­wa­ny sym­bol sta­no­wią­cy abs­trak­cję inter­fej­su ofe­ro­wa­ne­go. Wymienjony zasób REST” to wła­śnie opi­sa­na abs­trak­cyj­na kla­sa, zobra­zo­wa­na jak na rysun­ku powy­żej. Poniżej przy­kła­do­wy efekt czy­li doku­men­ta­cja API z uży­ciem powyż­szej metody:

Visual REST API Designer
(źr.: Visual Paradigm, Graphical API desi­gner for REST https://​www​.visu​al​-para​digm​.com/​f​e​a​t​u​r​e​s​/​v​i​s​u​a​l​-​a​p​i​-​d​e​s​i​g​n​er/)

Np. Bardzo pro­sta komu­ni­ka­cja (inter­fejs ofe­ro­wa­ny przez ERP, lub inter­fejs wymagany):

Prosty przy­kład doku­men­ta­cji meto­dy pobie­ra­nia Faktur z sys­te­mu ERP (dia­gram klas UML z ele­men­tem zasób REST”)

Na powyż­szym dia­gra­mie po lewej mamy pro­sty kla­syf­ka­tor poka­zu­ją­cy, że moż­li­we jest żąda­nie Faktury lub Zamówienia na pod­sta­wie typu i nume­ru ID doku­men­tu. Po pra­wej stro­nie (uprosz­cze­nie) zwró­co­na, jako wyni­ka żąda­nia, fak­tu­ra. Jeżeli nasz pro­jekt zawie­ra deta­licz­ną spe­cy­fi­ka­cję fak­tu­ry jako agre­ga­tu, odpo­wie­dzią był­by ten wła­śnie agre­gat, np. agre­gat w posta­ci XML zna­ny z doku­men­ta­cji JPK lub fak­tu­ry ustruk­tu­ry­zo­wa­nej (patrz tak­że: Dokument jako wyma­ga­nie).

Bardzo waż­na uwa­ga prak­tycz­na: pro­jek­to­wa­nie inte­gra­cji, jako wymia­ny danych, nale­ży reali­zo­wać w opar­ciu o kom­plet­ne doku­men­ty (zesta­wy danych): na API żąda­my Faktury VAT” i po jej otrzy­ma­niu u sie­bie” wycią­ga­my z niej np. Wartość brut­to”. Nie two­rzy­my (nie żąda­my od ser­we­ra) API i usłu­gi Podaj war­tość brut­to Faktury VAT()” bo to: dra­stycz­nie uza­leż­nia od sie­bie komu­ni­ku­ją­ce się apli­ka­cje, ogrom­nie pod­no­si kosz­ty imple­men­ta­cji i testo­wa­nia, wyma­ga powta­rza­nia całej tej pra­cy po każ­dej zmia­nie lub aktu­ali­za­cij ser­we­ra, wyma­ga dedy­ko­wa­nych ope­ra­cji dla każ­dej zin­te­gro­wa­nej apli­ka­cji u kon­tra­hen­ta .

Integracja, szcze­gól­nie apli­ka­cji pocho­dzą­cych od róż­nych pro­du­cen­tów, bar­dzo czę­sto wyma­ga mapo­wa­nia danych (tłu­ma­cze­nie). Wtedy naj­efek­tyw­niej­sze jest budo­wa­nie adap­te­rów inte­gra­cyj­nych, co chro­ni nas przez bar­dzo kosz­tow­nym mody­fi­ko­wa­niem (kasto­mi­za­cji) sys­te­mów integrowanych:

Integracja z mapo­wa­niem danych: adapter

W mniej­szych wdro­że­niach budu­je­my je jako pro­ste dedy­ko­wa­ne apli­ka­cje, więk­sze wdro­że­nia mogą wyma­gać szy­ny inte­gra­cyj­nej (ang. ESB, Enterprise Service Bus)

Modelowanie interakcji

Powyższe sta­tycz­ne mode­le archi­tek­tu­ry poka­zu­je­my tak­że z per­spek­ty­wy inte­rak­cji użyt­kow­ni­ka z sys­te­mem, mię­dzy sys­te­ma­mi i mię­dzy kom­po­nen­ta­mi systemu. 

Podsumowanie

Tak więc pogo­dze­nie się z inte­gra­cją jako wyma­ga­niem jest nie­unik­nio­ne. Podobnie jak pogo­dze­nie się z tym, że cza­sy jed­nej cen­tral­nej apli­ka­cji w fir­mie i cen­tral­nej bazy danych, też ode­szły do lamu­sa. Mamy ogól­no­świa­to­wą sieć Internet, apli­ka­cje lokal­ne i w chmu­rze, apli­ka­cje naszych kon­tra­hen­tów i apli­ka­cje cen­tral­nych urzę­dów. Wszystkie on współ­pra­cu­ją, wymie­nia­ją dane. To dla­te­go inte­gra­cja sta­ła się jed­nym z obli­ga­to­ryj­nych wyma­gań każ­de­go sys­te­mu informatycznego. 

A po co ta doku­men­ta­cja? Pełni iden­tycz­ną rolę jak dobrze zapla­no­wa­na tra­sa podró­ży: wszyst­ko to co moż­na spraw­dzić na mapie przed podró­żą pozwo­li unik­nąć kosz­tow­nych nie­spo­dzia­nek w jej trak­cie. To zna­czy tak­że, że moż­na prze­ka­zać to jako wymaganie.

Poniżej pre­zen­ta­cja poka­zu­ją­ca zale­ty podej­ścia Design First, czy­li naj­pierw pro­jek­tu­je­my inte­gra­cje a potem dopie­ro pisze­my kod i implementację. 

API Design First principles

Dwa słowa porównania: monolit vs. pakiet aplikacji dziedzinowych

Wiele razy sły­sza­łem o wadach sys­te­mów poin­te­gro­wa­nych”… No to porównajmy: 

EtapSystem mono­li­tycz­nyZintegrowane apli­ka­cje dziedzinowe
Zakupjed­na licen­cja na całość (mono­pol dostaw­cy; ven­dor lock-in) w jed­nej umo­wie, roz­ło­że­nie kosz­tów w cza­sie, to raty za jeden pro­dukt, wdro­że­nie musi się zacząć od modu­łów finansowych, dobie­ra­my na ryn­ku to co jest aku­rat potrzeb­ne, moż­li­we roz­ło­że­nie w cza­sie kosz­tów i wdro­że­nia, dowol­na kolej­ność wdra­ża­nia modu­łów, brak mono­po­lu jed­ne­go dostawcy
Wdrożeniezawsze całość z uwa­gi na jed­ną współ­dzie­lo­ną bazę danych, sys­tem albo jest wdro­żo­ny w cało­ści albo nie dzia­ła popraw­nie, każ­de dosto­so­wa­nie to inge­ren­cja w całość (współ­dzie­lo­ne dane)nie ma przy­mu­su wymia­ny już posia­da­ne­go sys­te­mu FK, zamiast kasto­mi­za­cji, dobie­ra­ne są naj­bar­dziej pasu­ją­ce kom­po­nen­ty na ryn­ku, zmia­na stra­te­gii wdro­że­nia moż­li­wa na każ­dym etapie
Utrzymanie i rozwójkaż­da zmia­na to zawsze inge­ren­cja w cały sys­tem, co gene­ru­je duże kosz­ty i czas przy każ­dej mody­fi­ka­cji, upgra­de ozna­cza prak­tycz­nie powtó­rze­nie cza­su i kosz­tu wdro­że­nia, a czę­sto tak­że i migra­cję danychinge­ru­je­my wyłącz­nie w jeden z kil­ku ele­men­tów sys­te­mu, taka zmia­na nie prze­no­si się na inne apli­ka­cje i obsza­ry dzia­ła­nia fir­my, zmia­na stra­te­gii fir­my może wyma­gać wymia­ny kom­po­nen­tu ale nigdy inge­ren­cji w cały system
Ryzykonie­uda­ne wdro­że­nie doty­czy z zasa­dy cało­ści sys­te­mu czy­li całej fir­my, przy­szłe ewen­tu­al­ne wydzie­le­nie spół­ki zależ­nej wraz z czę­ścią sys­te­mu IT nie jest możliwenie­uda­ne wdro­że­nie doty­czy wyłącz­nie jed­ne­go modu­łu, czy­li jed­ne­go obsza­ru fir­my, przy­szłe ewen­tu­al­ne wydzie­le­nie spół­ki zależ­nej wraz z czę­ścią sys­te­mu IT nie sta­no­wi problemu
PodsumowanieMało ela­stycz­ny, ryzy­kow­ny, bar­dzo kosz­tow­ny cykl życia, nie wyma­ga pro­jek­to­wa­nia. Bardzo ela­stycz­ny, znacz­nie tań­szy w utrzy­ma­niu i roz­wo­ju, wyma­ga dużych wie­dzy i doświad­cze­nia od pro­jek­tan­ta.
Porównanie klu­czo­wych cech wdro­żeń. Praktyka poka­zu­je, że wdro­że­nia mono­li­tycz­nych ERP nie uda­ją się w ok. 75%. Wdrożenia sys­te­mów kom­po­nen­to­wych obło­żo­ne są znacz­nie niż­szym ryzy­kiem, gdyż ryzy­ko nie­po­wo­dze­nia szyb­ko rośnie ze wzro­stem zakre­su poje­dyn­cze­go wdro­że­nia (patrz Chaos Report).

I uwa­ga: żaden mono­li­tycz­ny sys­tem ERP i tak nie obej­mie cało­ści przed­się­bior­stwa, elek­tro­nicz­na wymia­na danych z kon­tra­hen­ta­mi i insty­tu­cja­mi pań­stwo­wy­mi jest obec­nie wyma­ga­na, więc inte­gra­cja jest i tak nieunikniona.

Robot i Saga czyli jak integrować

Załóżmy, że mamy sytu­ację jak poniżej:

Struktura pię­ciu apli­ka­cji i linii wymia­ny danych mię­dzy nimi, tak­że z otoczeniem. 

Szkic poka­zu­je hipo­te­tycz­ne pięć apli­ka­cji i wymia­nę danych (linie) mię­dzy nimi oraz z oto­cze­niem (wszyst­kie orga­ni­za­cje teraz wymie­nia­ją dane z oto­cze­niem, w tym z Urzędem Skarbowym). 

Standardowe apli­ka­cje ofe­ru­ją API jako Interfejs Oferowany (lista usług, któ­re moż­na wywo­łać), czy­li moż­na od nich cze­goś żądać. Problem w tym, że ktoś musi to żąda­nie wysłać. Czy żąda­nie może wysłać sama z sie­bie inna apli­ka­cja? Owszem, pod warun­kiem że ma taką moż­li­wość (a ma rzad­ko), lub że doda­my jej (kasto­mi­za­cja) taką moż­li­wość. Robi się to na pozio­mie kodu (kasto­mi­za­cja) lub na pozio­mie bazy danych (tak zwa­ne try­ge­ry). W efek­cie powsta­je, poka­za­na poni­żej, struk­tu­ra wza­jem­nych wywo­łań, któ­rych nic nie koor­dy­nu­je (każ­da apli­ka­cja sama, w sobie zna­nym momen­cie, ini­cju­je żąda­nie wobec innej). 

Bezpośrednia inte­gra­cja apli­ka­cji (cho­re­ogra­fia)

Efekt jaki powsta­je to: tak zwa­ny hazard, pole­ga­ją­cy na tym, że nic nie panu­je nad kolej­no­ścią tych wywo­łań. Taki hazard powo­du­je błę­dy lub zawie­sze­nia się komu­ni­ka­cji. Próby wal­ki z nim pole­ga­ją na sztucz­nym wsta­wia­niu cza­su ocze­ki­wa­nia, lub wymu­sza­niu okre­ślo­ne­go ter­mi­nu wywo­ła­nia. Koszty inte­gra­cji to koszt tych prac kasto­mi­za­cyj­nych razy licz­ba apli­ka­cji wyma­ga­ją­cych tej kasto­mi­za­cji, całość jest czu­ła na każ­dą zmia­nę takiej sie­ci bo np. mody­fi­ka­cja lub wymia­na jed­nej z apli­ka­cji, poten­cjal­nie wyma­ga reor­ga­ni­za­cji całej komu­ni­ka­cji. To tyl­ko część pro­ble­mów, gdyż bar­dzo czę­sto inte­gra­cje nadal są reali­zo­wa­ne meto­dą bez­po­śred­nie­go dostę­pu do danych (i wte­dy fak­tycz­nie są bar­dzo kosz­tow­ne) jak poka­za­no poniżej:

Integracja apli­ka­cji jako bez­po­śred­ni dostęp do danych. Dodatkowe pra­ce nad two­rze­nie skom­pli­ko­wa­nych zapy­tań SQL do cudzych danych. 

Szkodliwość podej­ścia poka­za­ne­go powy­żej jest podwój­na: pomi­ja­my logi­kę biz­ne­so­wą w opro­gra­mo­wa­niu Aplikacja2, kasto­mi­zu­je­my opro­gra­mo­wa­nie Aplikacja1. Kastomizacja to duży dodat­ko­wy koszt, ryzy­ko desta­bi­li­za­cji obu apli­ka­cji (bar­dzo czę­sto się to zda­rza) i bar­dzo czę­sto powta­rza­nie tych prac jest koniecz­ne po każ­dym upgra­de (wię­cej w arty­ku­le Wymagania poza­funk­cjo­nal­ne ? inte­gra­cja). Taka inte­gra­cja i jej wady są czę­sto uży­wa­nym argu­men­tem dostaw­ców mono­li­tycz­nych sys­te­mów ERP, jed­nak teza, że inte­gra­cja pole­ga na współ­dzie­le­niu danych to wła­śnie dema­go­gia tych dostawców. 

Popatrzmy teraz na poniż­szy szkic:

Serwer koor­dy­nu­ją­cy wymia­nę danych (dedy­ko­wa­ny adap­ter lub szy­na inte­gra­cyj­na ESB)

Korzyści: nie musi­my kasto­mi­zo­wać apli­ka­cji bo np. ESB ma wbu­do­wa­ny mecha­nizm pro­jek­to­wa­nia wywo­łań API, ESB izo­lu­je od sie­bie ser­we­ry apli­ka­cji: są one her­me­ty­zo­wa­ne za pomo­cą adap­te­rów (budu­je­my je np. uży­wa­ją ESB lub jako samo­dziel­ne ele­men­ty apli­ka­cji), więc zmia­na kon­fi­gu­ra­cji apli­ka­cji, lub jej wymia­na na inną, wyma­ga jedy­nie inge­ren­cji w jej adap­ter. Zastępujemy cał­ko­wi­cie indy­wi­du­al­ne inte­gra­cje z apli­ka­cja­mi kon­tra­hen­tów jed­nym cen­tral­nym węzłem inte­gra­cji (to tak­że for­ma her­me­ty­za­cji lokal­nej sie­ci). W efek­cie poszcze­gól­ne apli­ka­cje nie wyma­ga­ją żad­nych prac kasto­mi­za­cyj­nych, nie docho­dzi do opi­sa­nych desta­bi­li­za­cji i hazar­du, każ­da wymia­na danych jest bez­piecz­ną trans­ak­cją kon­tro­lo­wa­ną przez ESB zgod­nie z wzor­cem Saga . Poniżej przy­kład z uży­ciem ESB i wzor­ca Saga: 

Integracja z uży­ciem ESB. Szyna może tak­że reali­zo­wać okre­ślo­ne wyma­ga­ne dodat­ko­we prze­twa­rza­nie, któ­re­go nie reali­zu­je żad­na stan­dar­do­wa apli­ka­cja (krok 8). 

Wyżej opi­sa­ne podej­ście ma tak­że dodat­ko­wą ogrom­ną zale­tę: dostaw­cy poszcze­gól­nych apli­ka­cji nie muszą ze sobą nicze­go uzgad­niać ani nego­cjo­wać, co bywa dłu­gie i bar­dzo kosz­tow­ne. Mogą być wybie­ra­ni nie­za­leż­nie od sie­bie, w róż­nym cza­sie, i nie zakłó­ca­ją wza­jem­nie swo­imi pra­ca­mi wdro­że­nio­wy­mi zacho­wa­nia innych apli­ka­cji. To efekt sepa­ra­cji apli­ka­cji: żad­na nie współ­dzie­li danych bez­po­śred­nio z inną, ma miej­sce tyl­ko wymia­na danych na pozio­mie logi­ki tych aplikacji. 

Czy to nie­bez­piecz­ne? Co będzie gdy uszko­dzi się ser­wer ESB? Obecnie zabez­pie­cze­nie jego dostęp­no­ści jest znacz­nie tań­sze (redun­dan­cja) niż budo­wa­nie i utrzy­ma­nie wie­lu łączy inte­gra­cji każ­dy z każ­dym”. Warto też zwró­cić uwa­gę na to, że może to być (ESB) usłu­ga chmu­ro­wa, więc jej wyso­ka jakość i dostęp­ność będzie czę­sto tań­sza niż wła­sny zasób. 

Jak Budujemy logi­kę inte­gra­cji? To opi­sa­łem w arty­ku­le Wzorce pro­jek­to­we… inte­gra­cje reali­zu­je­my na bazie wzor­ca SAGA , czy­li budu­je­my skryp­ty reali­zu­ją­ce wywo­ła­nia (pobra­nie i wysła­nie danych) w usta­lo­nej kolej­no­ści i w usta­lo­nym czasie. 

A Roboty? Słynne i mod­ne ostat­nio Roboty to wła­śnie te skryp­ty reali­zu­ją­ce sce­na­riu­sze inte­gra­cji na szy­nie ESB, zna­ne od kil­ku dekad .

Nieco więcej o wzorcach integracji

Enterprise Integration Patterns 2 ? Gregor Hohpe ? YOW! 2017

Polecam tak­że stro­nę auto­ra: https://​www​.enter​pri​se​in​te​gra​tion​pat​terns​.com/​i​n​d​e​x​.​h​tml

Źródła

Altan, Z. (Ed.). (2020). A General Overview of RESTful Web Services. IGI Global. https://​doi​.org/​1​0​.​4​0​1​8​/​978 – 1‑7998 – 2142‑7
Chen, D. Q., Mocker, M., Preston, D. S., & Teubner, A. (2010). Information sys­tems stra­te­gy: recon­cep­tu­ali­za­tion, measu­re­ment, and impli­ca­tions. MIS Quarterly, 34(2), 233 – 259.
Cutting, G. A., & Anne-Françoise Cutting-Decelle. (2021). Intelligent Document Processing – Methods and Tools in the real world. 28.
Dürr, K., Lichtenthäler, R., & Wirtz, G. (2021). An Evaluation of Saga Pattern Implementation Technologies. ZEUS, 74 – 82.
Garcia-Molina, H., & Salem, K. (1987). Sagas. ACM Sigmod Record, 16(3), 249 – 259.
Imane, B., Mammass, M., Abioui, H., Moutaoukkil, A., & Idarrou, A. (2022). Structural Information Retrieval in XML Documents: A Graph-based Approach. International Journal of Advanced Computer Science and Applications, 13. https://​doi​.org/​1​0​.​1​4​5​6​9​/​I​J​A​C​S​A​.​2​0​2​2​.​0​1​3​0​377
Jouini, K. (2022). Aggregates Selection in Replicated Document-Oriented Databases. 18.
Marinos, A., & Krause, P. (2009). An SBVR Framework for RESTful Web Applications. In G. Governatori, J. Hall, & A. Paschke (Eds.), Rule Interchange and Applications (Vol. 5858, pp. 144 – 158). Springer Berlin Heidelberg. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 04985-9_15
Martin Fowler. (2014). bli­ki: BoundedContext [Martinfowler​.com]. Martinfowler​.Com. https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​B​o​u​n​d​e​d​C​o​n​t​e​x​t​.​h​tml
Martin Fowler, & Martin Fowler. (2013). bli­ki: TellDontAsk [Martinfowler​.com]. Martinfowler​.Com. https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​T​e​l​l​D​o​n​t​A​s​k​.​h​tml
Pautasso, C. (n.d.). RESTful Web servi­ces: prin­ci­ples, pat­terns, emer­ging tech­no­lo­gies. Emerging Technologies, 22.
Porres, I., & Rauf, I. (2011). Modeling beha­vio­ral RESTful web servi­ce inter­fa­ces in UML. Proceedings of the 2011 ACM Symposium on Applied Computing – SAC 11, 1598. https://​doi​.org/​1​0​.​1​1​4​5​/​1​9​8​2​1​8​5​.​1​9​8​2​521
Porter, M. E. (1998). Competitive advan­ta­ge: cre­ating and susta­ining supe­rior per­for­man­ce: with a new intro­duc­tion (1st Free Press ed). Free Press.
Rauf, I., Ruokonen, A., Systä, T., & Porres, I. (2010). Modeling a com­po­si­te RESTful web servi­ce with UML. Proceedings of the Fourth European Conference on Software Architecture Companion Volume – ECSA 10, 253. https://​doi​.org/​1​0​.​1​1​4​5​/​1​8​4​2​7​5​2​.​1​8​4​2​801
Štefanko, M., Chaloupka, O., Rossi, B., van Sinderen, M., & Maciaszek, L. (2019). The Saga pat­tern in a reac­ti­ve micro­se­rvi­ces envi­ron­ment. Proc. 14th Int. Conf. Softw. Technologies (ICSOFT 2019), 483 – 490.
Document Content Description for XML. (1998, July 31). Document Content Description for XML. https://​www​.w3​.org/​T​R​/​N​O​T​E​-​dcd

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 8 komentarzy

  1. Na pew­nym forum w mediach spo­łecz­no­ścio­wych, padło pyta­nie o robo­ty­za­cję pro­ce­sów” i o to co to za nowa tech­no­lo­gia. Musiałem nie­co roz­cza­ro­wać pyta­ją­ce­go, bo odpi­sa­łem: nie jest to nic nowe­go poza nową nazwą. To co teraz mod­nie nazy­wa­my robo­ta­mi, to nie­wiel­ki pro­gram (micro­se­rvi­ce) reali­zu­ją­cy okre­ślo­ny sce­na­riusz zbu­do­wa­ny na bazie wzor­ca saga, inte­gru­ją­cy apli­ka­cje z uży­ciem REST API.

  2. Jarosław Żeliński

    Taka cie­ka­wost­ka:
    1. raport obej­mu­je 10 sys­te­mów ERP
    2. sys­te­my te powsta­ły w: 1972, 1983, 2002, 1975, 1998, 1977, 1981, 1972, 2008, 1986.

    Tylko dwa nazwał bym nowo­cze­sne”. Nie poda­ję nazw bo nie jest moim celem ich pro­mo­wa­nie (raport jest do pobra­nia za dar­mo, tam są peł­ne infor­ma­cje). Informacje w rapor­cie nie zawie­ra­ją opi­su archi­tek­tu­ry, jed­nak pew­ną wspól­ną cechą tych sys­te­mów jest to, że zawie­ra­ją zin­te­gro­wa­ne naj­lep­sze prak­ty­ki bran­żo­we i pro­ce­sy biz­ne­so­we” co zna­czy tyl­ko tyle, że ta logi­ka jest wbu­do­wa­na w model danych.

    Firmy te czę­sto pod­kre­śla­ją, że idą z duchem cza­su i są to zawsze naj­now­sze tech­no­lo­gie”, owszem, ale model danych i mono­li­tycz­ną archi­tek­tu­rę mają z cza­sów gdy powsta­wa­ły… Najnowsza tech­no­lo­gia to taki trik mar­ke­tin­go­wy typu a my mam block­cha­in”! Owszem, zamon­to­wa­ny do sto­do­ły z przed poło­wy wieku.

    Oldemeyer, J. (2023). Top 10 ERP Systems Report. Panorama Consulting Group.

    Czy te sys­te­my są złe? Nie, one są dedy­ko­wa­ne do kon­tek­stu, celu, bran­ży dla jakiej pier­wot­nie powsta­ły, ale są też ogrom­nie skom­pli­ko­wa­ne. To zna­czy, że nale­ży RYGORYSTYCZNIE prze­strze­gać metod ich wdra­ża­nia zale­ca­nych przez ich producentów:
    1. Analiza pro­ce­sów biz­ne­so­wych fir­my (dodam, że koniecz­nie wraz z ana­li­zą onto­lo­gii i struk­tur doku­men­tów biz­ne­so­wych!), oraz ich zmia­na jeśli oka­że się że pod­nie­sie­nie efek­tyw­no­ści jest moż­li­we (a po wie­lu latach sta­gna­cji firm, pra­wie zawsze można).
    2. Analiza fit-gap sys­te­mu ERP i tych modeli.
    3. Zakreślić zakres wdro­że­nia ERP: tyl­ko to co pasu­je w 100% i nic ponad to! Kastomizajca (inge­ren­cja w kod i bazę danych) jest klu­czo­wym powo­dem pora­żek ich wdrożeń.
    4. Dla bra­ku­ją­cych funk­cjo­nal­no­ści poszu­kać na ryn­ku dzie­dzi­no­wych roz­wią­zań i zin­te­gro­wać z ERP, lub zapro­jek­to­wać i wyko­nać add-on (dedy­ko­wa­ny i inte­gro­wa­ny moduł w śro­do­wi­sku dewe­lo­per­skim ERP).

    Kto to powi­nien zrobić?
    ad.1. to robi­my przed wybo­rem sys­te­mu ERP
    ad.2. to robi dostaw­ca ERP na eta­pie skła­da­nia oferty
    ad.3. to robi dostaw­ca ERP wybra­ny na bazie powyż­sze­go (naj­mniej­sza luka fit-gap)
    ad.4. pro­jek­tan­tem cało­ści powin­na być zawsze oso­ba, któ­ra wyko­na­ła ana­li­ze (pkt.1.) i ma kom­pe­ten­cje i doświad­cze­nie do wyko­na­nia pkt. 4. oraz nad­zo­ru nad cało­ścią, ta oso­ba powin­na pra­co­wać po stro­nie Zamawiającego! Implementację robi dostaw­ca ERP, ale pra­wa autor­skie do add-on zosta­ją przy Zamawiającym bo to jego know-how.

    Potrzebujesz wię­cej infor­ma­cji? Zapraszam.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.