Kwa maoni yangu, kuna njia mbili za kuunda basi ya ujumuishaji wa biashara:

• "kutoka kwa mifumo iliyojumuishwa";


• "kutoka kwa michakato inayotekelezwa."

Hebu tuangalie mbinu hizi kwa undani zaidi.

Mbinu ya "mifumo shirikishi".

Katika hali hii, basi ya kuunganisha inachukuliwa kama aina ya usafiri ambayo hubeba njia na mazungumzo ya itifaki za kubadilishana ujumbe. Ujumbe wote hupita kwenye mlolongo: chaneli ya ingizo ya adapta ya mfumo wa chanzo -> kipanga njia -> chaneli ya pato ya mfumo wa kupokea. Aina ya mawasiliano kati ya vipengele hivi na teknolojia mahususi hutegemea ikiwa ujumbe unaotoka kwa mfumo mmoja wa chanzo unaweza kuwa na mifumo mingi lengwa, mzigo unaotarajiwa, na mbinu ya kuhakikisha uadilifu wa data (kutumia muamala wa kawaida kwa mifumo yote ya chanzo, au data kuhamishwa kwa kila mfumo wa chanzo katika shughuli zake).

1. Utegemezi wa mifumo, sio aina za ujumbe. Kwa kawaida, idadi ya mifumo iliyounganishwa ni mara kadhaa chini ya idadi ya aina za ujumbe unaopitishwa.


2. Urahisi wa kuunganisha mifumo mpya ya mpokeaji: kuunganisha mfumo mpya wa mpokeaji, ingiza tu data kwenye jedwali la uelekezaji.


3. Urahisi wa utekelezaji wa mfumo wa ufuatiliaji kwa ufumbuzi wa ushirikiano: data kwa ajili ya mfumo wa ufuatiliaji inaweza kuzalishwa katika sehemu moja - katika router (hatua hii, hata hivyo, inaweza kukubaliwa tu na kutoridhishwa, kwa kuwa kuna data inayozalishwa tu katika adapters. ya mifumo iliyojumuishwa).


4. Urahisi wa msaada wa suluhisho. Kwa kuwa ujumbe wote hupitia router moja, mantiki yote ya kupeleka ujumbe na kufuatilia utegemezi kati ya ujumbe inaweza kutekelezwa katika sehemu moja - katika router hii.


5. Sharability ya mfumo kati ya watengenezaji. Kwa kuwa msingi wa mfumo na adapta zote ni huru kwa kila mmoja (mawasiliano hutolewa tu kwa njia ya interfaces zilizojitolea na zilizoelezwa), kazi za maendeleo yao zinaweza kugawanywa kati ya waandaaji wa programu, ambayo inaruhusu mchakato wa kuunda na kutekeleza ufumbuzi wa ushirikiano kuwa sambamba.

1. Suluhisho linatumika tu kwa utekelezaji wa mantiki ya kupitisha ujumbe, i.e. ikiwa kuna ufuatiliaji wa utegemezi na sheria za mabadiliko zinazofanana kwa ujumbe wote au zaidi. Ikiwa aina tofauti za ujumbe zina mantiki tofauti kabisa ya kufuatilia utegemezi na kusimamia ubadilishanaji, italazimika kuhamishiwa kwa adapta, ambayo inapuuza faida ya 4, au haitawezekana kutekeleza kabisa.


2. Mpango huu unafaa kwa kutekeleza ubadilishanaji wa asynchronous. Katika kesi ya kubadilishana synchronous au mchanganyiko, utata wa kutekeleza mbinu hii huongezeka kwa kiasi kikubwa.


3. Kunaweza kuwa na kupungua kwa utendaji wa suluhisho. Kwa mfano, ikiwa ujumbe lazima usambazwe kwa kila moja ya mifumo lengwa katika shughuli tofauti, ni muhimu kutenganisha mfumo wa chanzo, kernel na mifumo lengwa na foleni. Foleni hizi zinaweza kuwa kikwazo cha mfumo.

Mbinu inayotegemea mchakato

Katika kesi hii, kila mchakato wa biashara unaohitaji kubadilishana data kati ya mifumo kadhaa unazingatiwa tofauti. Basi hutekeleza ubadilishanaji huu. Tukio ambalo linaanzisha mchakato wa kubadilishana ni upokeaji wa ujumbe kutoka kwa mfumo wa chanzo. Ujumbe uliopokelewa kutoka kwa mfumo wa chanzo hupitishwa kwa mfumo wa mpokeaji mmoja au zaidi, na sio kazi za usafiri tu zinazotekelezwa, lakini matokeo ya usindikaji wa ujumbe pia hufuatiliwa na ujumbe unaopitishwa unahusishwa na wengine.

Mbinu hii ina faida zifuatazo:

1. Kubadilika. Mbinu hii hukuruhusu kutekeleza mantiki yako tofauti ya kubadilishana kwa kila aina ya ujumbe. Mantiki hii inaweza kuwa isiyo ya maana kabisa.


2. Utata wa kutekeleza ubadilishanaji wa asynchronous na synchronous ni takriban sawa.


3. Uhuru wa nyuzi, au tuseme, katika kesi hii ni sahihi zaidi kuzungumza juu ya michakato. Maamuzi ya kiufundi yaliyofanywa wakati wa utekelezaji wa mchakato mmoja wa kubadilishana haiathiri utata wa utekelezaji wa mwingine.

Mbinu hii ina hasara zifuatazo:

1. Utegemezi wa aina za ujumbe. Kwa kawaida, idadi ya aina za ujumbe ni mara nyingi zaidi ya idadi ya mifumo iliyounganishwa. Wakati wa kuunganisha mfumo mpya wa chanzo kwa basi, ni muhimu kusambaza ujumbe kwa aina na kutekeleza mchakato wake wa kubadilishana kwa kila aina ya ujumbe.


2. Ikiwa mantiki sawa ya kubadilishana lazima itekelezwe kwa aina kadhaa za ujumbe, basi kurudia kwa msimbo na/au mipangilio ya basi inawezekana.


3. Michakato ya kupitisha ujumbe inategemea adapta za mfumo na inaweza kutegemeana, pamoja na michakato ya huduma. Uwepo wa utegemezi huo hupunguza kiwango cha usawa wa mchakato wa maendeleo na utekelezaji wa ufumbuzi wa ushirikiano. Waendelezaji wa vipengele vingine hutegemea matokeo ya kazi ya watengenezaji wa vipengele vingine vya ufumbuzi wa ushirikiano.

Uchaguzi wa mbinu unafanywa kulingana na algorithm ifuatayo:

1. Pokea kutoka kwa wachambuzi orodha na maelezo ya mifumo iliyounganishwa na aina za ujumbe.


2. Pokea kutoka kwa wachambuzi orodha na maelezo ya michakato ya biashara inayohusisha mifumo inayohitaji ujumuishaji.


3. Ikiwa michakato ni ndogo na kuna mifumo michache zaidi kuliko aina za ujumbe, ubadilishanaji haufanani, na uhamishaji wa ujumbe mmoja kwa mifumo kadhaa inahitajika - tunachagua njia ya kwanza. Tunaamua juu ya sera ya usimamizi wa shughuli.


4. Ikiwa michakato inahusisha ubadilishanaji wa synchronous kwa kiasi kikubwa, na taratibu ni ngumu, i.e. kifungu cha ujumbe kinategemea matokeo ya usindikaji wake katika mifumo ya kupokea, kisha tunachagua njia ya pili. Hoja inayounga mkono mbinu hii inaweza pia kuwa ukweli kwamba idadi ya aina za ujumbe inalinganishwa na idadi ya mifumo iliyojumuishwa.

Inahitajika kuelewa wazi kuwa njia hizi za utekelezaji sio nadharia, sio lazima kuchagua njia ya kwanza tu au ya pili tu. Wanaweza kuunganishwa kila wakati, mabasi ya kisasa ya huduma ya biashara ( E.S.B.) kukuruhusu kufanya hivi.

Nilipenda ujumbe -

Blogu ya kampuni ya PNN,

Maendeleo ya tovuti

Kwa makala hii ningependa kufungua mfululizo uliotolewa kwa IBM WebSphere ESB (hapa inajulikana kama ESB) katika muktadha wa maendeleo ya bidhaa hii. Na, kwanza kabisa, itabidi ujue zaidi teknolojia za aina hii.
Basi la huduma ya biashara (basi la huduma ya biashara) ni programu ya kati ambayo hutoa ujumbe wa kati na wa umoja unaoendeshwa na matukio kati ya mifumo mbalimbali ya habari kulingana na kanuni za usanifu unaozingatia huduma.
Bila shaka, unaweza kujenga mfumo wa ushirika kulingana na mbinu hii bila programu maalum (unaweza bado kuendeleza kitu cha jumla) na kuiita bidhaa inayotokana na basi ya huduma. Lakini bidhaa kutoka kwa IBM haina tu kifaa kilichotengenezwa tayari kwa ujumbe wa kati na udhibiti wa mchakato huu, lakini pia seti kamili ya uwezo wa kuunda programu nyumbufu zinazoelekezwa kwa huduma haswa kwa ESB. Kama matokeo, tunaweza kuangazia uwezo na faida zifuatazo za IBM WebSphere ESB:

• Utaratibu na usawa wa viunganisho vya usanifu
• Usimamizi wa serikali kuu
• Usanidi wa programu ya upande wa seva
• Utekelezaji wa teknolojia ya Usanifu wa Sehemu ya Huduma (SCA) katika roho ya kanuni za usanifu zinazoelekezwa kwa huduma.
• Uhuru wa itifaki ya msimbo wa programu uliotengenezwa
• Chaguzi pana za usanidi wa basi na programu

Wakati huo huo, ESB hutoa udhibiti wa shughuli, ubadilishaji wa data, usalama na uwasilishaji wa uhakika wa ujumbe. Upatikanaji wa huduma zote za huduma kupitia hatua moja inakuwezesha kusanidi mawasiliano ya huduma katikati. Unaweza pia kudhibiti matukio ya kutofaulu katika serikali kuu kwa kushughulikia makosa mengi.
Topolojia ya kawaida ya mkusanyiko wa ESB ni nguzo ambayo hutoa usawa wa scalability na uvumilivu wa makosa. Kulingana na mapendekezo rasmi, kuongeza idadi ya washiriki wa nguzo huongeza utendaji kwa ufanisi zaidi kuliko kuongeza nguvu za seva katika topolojia ya kusimama pekee. Kwa kuongeza, nguzo inaweza kuwashwa upya (au sehemu yake inaweza kushindwa) bila kuacha huduma.
Kwa kawaida, ESB hutumiwa kama safu ya huduma katika IBM BPM, lakini inaweza kuwa na jukumu kuu katika kujenga kielelezo cha mwingiliano kati ya mifumo ya shirika kama kifaa chenye nguvu cha kuunganisha (ikimaanisha ESB kama programu jalizi kwa Seva ya Maombi ya IBM WebSphere) .
Hii, kwa kweli, inahitajika kutoka kwa ESB, kwa kuwa ni "hatua ya kukusanya huduma" - ikiwa unahitaji huduma ambayo itafanya kazi na huduma zingine (labda za nje), basi mahali pazuri zaidi pa kufanya ujumuishaji kati ya huduma hizi ni juu. ya ESB. Kwa huduma za nje au tofauti, unaweza kuifunga kwa huduma ya ESB. Wacha tuonyeshe kwa ufupi urahisi wa kutumia "nyumba moja" kwa huduma:

Agizo
Mfumo mkubwa, utaratibu muhimu zaidi na usawa ni. Ikiwa tunazungumza juu ya tata ya mifumo ya biashara kubwa, basi inaweza kuitwa mfumo wa ukubwa mkubwa. Bila shaka, unaweza daima kupata msimamizi ambaye ana kichwani mwake mchoro wa mwingiliano wa mamia ya seva, au rundo la nyaraka zisizohusiana kwa kila moduli ya programu, ambayo inaelezea nini na jinsi inavyoingiliana.


Lakini ni rahisi zaidi kuwa na huduma (ESB) ambayo inaruhusu mwingiliano wote kutokea kupitia yenyewe. Kwa njia hii, sehemu ya usanifu wa mwingiliano katika mfumo mdogo tayari iko wazi - hakuna fujo katika viunganisho kati ya mifumo, seva na programu: kila kitu kimeunganishwa na ESB na ESB imeunganishwa kwa kila kitu.

Usimamizi wa serikali kuu
Daima ni rahisi zaidi kusanidi mifumo ya serikali kuu - iwe ni usanidi, urekebishaji kwa seva zinazosonga, kuhakikisha uvumilivu wa hitilafu, usambazaji wa mzigo, kushughulikia makosa, au ufuatiliaji na uchanganuzi.


Kwa mfano, wakati wa kusonga seva ya hifadhidata, hauitaji kwenda kwenye usanidi wa seva zote zilizopo za programu, na katika mipangilio ya programu maalum haswa - inatosha kuwa na tofauti ya mazingira katika ESB, ambayo inabainisha hifadhidata. anwani, na kisha mabadiliko yatahitaji kufanywa katika hatua moja tu.
Au, ikiwa moja ya mifumo ya nje haikupatikana kwa muda mrefu, na hakuna ombi moja kwake linapaswa kupotea, unaweza kutumia huduma hiyo kushughulikia matukio yaliyoshindwa ili "kutupa" ujumbe ambao haujawasilishwa wakati inafaa.
Ikiwa unahitaji kudhibiti idadi ya maombi ya wakati mmoja kwa mfumo wowote, au kufuatilia maombi haya, kuchambua mzigo, kuangalia vikwazo, unahitaji kwenda kwenye kituo cha udhibiti wa ujumbe - kwa console ya seva ya ESB.

Usanidi wa upande wa seva
"Nyumba moja" kwa huduma, kutoka kwa mtazamo wa usanidi, hufikia malengo kadhaa muhimu. Kwanza, hii ni utumiaji tena wa usanidi (sawa na utumiaji wa nambari na moduli, ambayo ni muhimu sana katika SOA), kwani moduli tofauti na programu zinaweza kutumia vigezo sawa vya uunganisho wa hifadhidata, rasilimali, vigezo vya uthibitishaji, anuwai ya mazingira, nk.


Pili, wakati wa kusanidi kwa upande wa seva, ni mazingira ya uendeshaji ya programu ambayo yanaweza kuathiri kwa kiasi kikubwa, ambayo hukuruhusu kuhamisha programu kati ya mizunguko tofauti (mtihani na uzalishaji), tune na hata kurekebisha mende bila kufanya mabadiliko kwenye programu.

Kwa kunufaika na manufaa haya yote, programu-tumizi huwa kama kinyonga—zinanyumbulika sana hivi kwamba zinakuwa sehemu ya mazingira ambamo zinafanya kazi, huku zikiendelea kutoa utendakazi muhimu.

Lakini unyumbufu wa programu zinazoendeshwa kwenye IBM WebSphere ESB hauzuiliwi kwa mazingira ambamo zinaendesha. Uwezo wa maendeleo hutoa mchango mkubwa katika hili. Kwa kuwa mifumo haihitaji tu kupatikana, wapi kukimbia, lakini pia inahitaji kuendelezwa na kusafishwa, pointi hizi za kuvutia haziwezi kukosa:

SCA
Usanifu huu unategemea kanuni kwamba sehemu hutoa utendaji wake kama huduma ambayo inapatikana kwa vipengele vingine. Ndani ya moduli moja, vipengele ni vizuizi vya programu (msimbo wa java) ambao hutekeleza kikamilifu utendakazi fulani ulioelezewa na kiolesura husika. Mantiki ya utekelezaji wa vipengele inatekelezwa kwa kuviunganisha katika muundo kulingana na miingiliano na marejeleo (Rejea ya Washirika).

Muundo wa moduli hii ni rahisi sana kukuza, kujaribu, kukuza, kubadilisha na kudumisha. Atomiki ya utendaji unaotekelezwa katika vipengele inakuwezesha kuendesha vipengele kwa ujumla bila kushuka kwa kiwango cha msimbo. Kwa upande mwingine, ni muhimu kimantiki kutokana na utekelezaji wa vipengele katika muktadha wa shughuli.
Kila sehemu ina kiolesura ambacho utekelezaji wake hutoa. Kwa hivyo, wakati wa kuunganisha vipengele pamoja, hakuna haja ya kujua vipengele vyao vya ndani - ni vya kutosha kwamba wanatekeleza miingiliano muhimu.
Kutumia usanifu huu, inawezekana pia kutatua kazi zote zinazohitaji kazi sambamba, bila usimamizi wa thread "mwongozo" (kwa mfano, unaweza kupiga simu za asynchronous kwa vipengele kadhaa na majibu ya kuchelewa).
Vipengele visivyo vya java, kwa mfano, aina za Export na Import, kuruhusu kutoa huduma kwa matumizi ya nje au kutumia huduma za nje, kwa mtiririko huo; Kipengele cha Mtiririko wa Upatanishi hutoa ufikiaji wa kiwango cha chini kwa ujumbe unaobadilishwa kati ya vipengee vingine na inaruhusu mabadiliko mbalimbali wakati wa kufanya kazi na miingiliano tofauti.
Mbali na miingiliano, mfumo wa kitu cha biashara cha IBM hutoa uwezo muhimu sana. Vitu vya biashara (BO), vinavyowakilishwa na michoro ya xsd, hutumiwa kama vitu vya kuhamisha data katika miingiliano, kati ya vipengee na kwa mawasiliano kati ya moduli. Zimeunganishwa moja kwa moja, kwa mfano, katika mpango wa wsdl wa kuelezea huduma za wavuti. Hiyo ni, kwa mfano, ikiwa moduli "A" hutoa utendaji wake katika mfumo wa huduma ya wavuti, kuitumia, moduli "B" inahitaji tu kuunganisha kiolesura na BO zilizotengenezwa tayari, na itaweza kufanya kazi kikamilifu. na huduma kama hiyo bila kuunda java -objects zozote za upitishaji data. BO pia ni rahisi kutumia wakati wa kubadilishana data na hifadhidata, ikiwa data hii inatumiwa na vifaa vingine (hii, bila shaka, inaenda kinyume na muundo wa "DAO", lakini huondoa vitu visivyo vya lazima vya java na shughuli za kuandika tena data "na kurudi" )

Itifaki-uhuru wa msimbo wa programu
Kama unavyoona, uhuru wa itifaki wa nambari hupatikana kwa kutumia vifaa vya Kusafirisha na Kuagiza. Kwa kuwa mawasiliano na vipengele hivi hutokea kupitia miingiliano na marejeleo, msimbo wa programu ni huru kabisa na itifaki inayotumiwa kwa mwingiliano. Utendaji sawa unaweza kupatikana kwa urahisi juu ya idadi yoyote ya itifaki zinazotumika na juu ya miingiliano yoyote inayohitajika. Kielelezo kifuatacho kinaonyesha kuongeza uhamishaji kwa SCA inayofunga kijenzi ambacho tayari kinafichua kiolesura chake kama HTTP, JMS na huduma ya Wavuti.


faida ni dhahiri - kubadilika, versatility, matumizi ya kanuni, kasi ya maendeleo na muundo.
Kwa njia, SCA kisheria hutumia itifaki maalum na inalenga kwa mawasiliano kati ya modules ndani ya seva / nguzo sawa. Mawasiliano kupitia uunganishaji huu hayahitaji rasilimali nyingi na ya haraka kuliko itifaki zingine.

Usanidi
Usanidi wa seva na programu hufanywa kupitia koni ya IBM ya seva.
ESB, kama IBM WebSphere kwa ujumla, ina uwezo mwingi maalum na mabaki. Kwa mfano, unapotumia uagizaji na usafirishaji sawa, unaweza kusanidi sehemu za mwisho za huduma zinazolingana "kwa kuruka". Kwa simu za huduma, unaweza kusanidi seti za sera na sheria mbalimbali (kwa mfano, unaweza kusakinisha usaidizi kwa utaratibu wa WS-AT, ambao hukuruhusu kupiga huduma ya wavuti katika shughuli ile ile ambayo mteja anaendesha; lakini muamala ni mada kwa makala kamili), weka vigezo vya uthibitishaji, unganisha vyeti, nk.
Kupitia usanidi, unaweza kusanidi mifumo kadhaa ya kujibu kiotomatiki hali za kipekee (kwa mfano, kurudia kiotomati utekelezaji wa vifaa ikiwa kuna makosa). Unaweza kusanidi ufuatiliaji wa kijenzi au kubadilisha viwango vya ukataji kwa kuruka. Huduma ya usimamizi wa matukio ya kushindwa inapatikana pia, ambayo inaweza kutumika kimakusudi kwa kushughulikia makosa mengi.
Na, kwa kweli, unaweza kusanidi vitu vingine vingi kulingana na uainishaji wa Java2EE, ambayo, wakati mwingine madhubuti, inatekelezwa katika Seva ya Maombi ya IBM.

Yote yaliyo hapo juu yanaanzisha ESB kama kifaa cha kuunganisha kinachofaa, chenye nguvu na rahisi, ingawa si rahisi kujifunza kila wakati. Katika siku zijazo, unahitaji tu kujifunza jinsi ya kuitumia.

Picha zifuatazo hutumiwa katika makala:

Maombi ya kisasa mara chache hufanya kazi kwa kutengwa; programu haiwezi kufanya chochote cha maana bila kuingiliana na programu zingine. Usanifu unaolenga huduma huunganisha programu za ushirikiano na kuziharakisha kwa kuvunja programu katika sehemu zinazoweza kuunganishwa. Mfano wa SOA (watumiaji wa huduma huita watoa huduma) inaweza kuonekana kuwa rahisi, lakini inazua masuala mawili muhimu:

1. Je, mtumiaji anawezaje kupata mtoa huduma anayotaka kupiga simu?
2. Je, mtumiaji anawezaje kuomba huduma kwa haraka na kwa uhakika kwenye mtandao wa polepole na usiotegemewa?

Inabadilika kuwa kuna suluhisho la moja kwa moja kwa shida zote mbili - njia inayoitwa Enterprise Service Bus (ESB). ESB hurahisisha mtumiaji na mtoa huduma kuomba huduma, kudhibiti mwingiliano changamano kati yao. ESB hairahisishi tu kwa programu (au sehemu za programu) kupiga huduma, lakini pia huwasaidia kuwasiliana data na kusambaza arifa za matukio. Muundo wa ESB hutekeleza miundo mingi inayotambulika ya muundo na vipimo vya viwango.

Niliandika makala hii ili kukusaidia, msanidi programu, kuelewa kwa nini ESB ni sehemu muhimu na muhimu ya ushirikiano wa maombi, ikiwa ni pamoja na SOA. Nakala hii haijumuishi ufafanuzi au bidhaa, lakini inaangazia vipengele na uwezo wa ESB ambao hutakiwi kutekeleza mwenyewe. Nakala hii inaelezea kile ESB inakufanyia.

Huduma za kupiga simu

Ili kukusaidia kuelewa ujumuishaji wa programu na SOA, nitaanza kwa kuangalia jinsi huduma za Wavuti zinavyofanya kazi. Huduma za wavuti ndio njia pekee ya kutekeleza simu ya huduma. Hii inaweza hata kuwa njia bora, lakini ni mbinu sanifu zaidi inayopatikana kwa sasa, na huduma za Wavuti husaidia kuongoza muundo, ambayo ndio ninakusudia kufanya.

Kwanza, lazima nieleze istilahi. Huduma ya Wavuti ni kama kazi katika upangaji wa utaratibu: ina jina, vigezo, na matokeo. Jina ni Kitambulisho cha Rasilimali Sare(URI - Kitambulisho cha Rasilimali Sare) mtoaji Huduma za wavuti hutumiwa kufanya huduma ya Wavuti ipatikane kama mwisho. Mtoa huduma wa Wavuti hutumia mwisho wa URI kama anwani kutafuta na kuomba huduma ya Wavuti. KATIKA ombi Kuna hatua maalum na vigezo ambavyo mtumiaji hupitisha kwa huduma ya Wavuti wakati anaita mwisho. Baada ya huduma kukamilika, sehemu ya mwisho inatuma jibu kurudi kwa mtumiaji, ambayo inaripoti mafanikio (au makosa) na ina matokeo ya huduma. Hiyo ni, mtumiaji huita mwisho wa mtoa huduma, hutuma ombi, na kupokea majibu.

Ufafanuzi wa sasa wa jinsi ya kutekeleza huduma ya Wavuti ni WS-I Basic Profaili 1.1, ambayo inajumuisha itifaki ya "SOAP 1.1 over HTTP 1.1" iliyofafanuliwa katika Lugha ya Maelezo ya Huduma za Wavuti (WSDL) 1.1 (kiungo cha maelezo yenyewe kimetolewa katika sehemu ya ""). Katika SOAP juu ya HTTP, mtumiaji huita huduma kwa kutumia ombi la SOAP lililotumwa kupitia HTTP katika ombi la HTTP. Mtumiaji huzuia kwa usawaziko kwenye soketi ya HTTP, akisubiri jibu la HTTP lililo na jibu la SABUNI. API ya sehemu ya mwisho inaelezewa na WSDL, mkataba kati ya mtumiaji na mtoa huduma.

Kwa kuwa sasa unaelewa istilahi, hebu tuangalie chaguo za jinsi mtumiaji hufanya kazi wakati wa kupiga huduma: simu zinazolingana na zisizo sawa.

Ulinganisho wa simu za synchronous na asynchronous

Mtumiaji anaweza kuita huduma kwa usawazishaji au asynchronously. Kwa mtazamo wa watumiaji, tofauti ni kama ifuatavyo.

• Sawazisha. Mtumiaji hutumia thread moja kupiga huduma; thread inatuma ombi, huzuia wakati huduma inaendesha na inasubiri majibu;
• Asynchronous. Mtumiaji hutumia nyuzi mbili kupiga huduma; moja ni ya kutuma ombi, ya pili ni ya kupokea majibu.

Dhana isiyolingana Na ya kusawazisha mara nyingi huchanganyikiwa na dhana thabiti Na sambamba. Dhana za mwisho zinarejelea mpangilio ambao kazi mbalimbali hufanywa, wakati ya kusawazisha Na isiyolingana shughulika na jinsi nyuzi hufanya kazi moja, kama vile kupiga huduma moja. Njia nzuri ya kuelewa tofauti kati ya simu inayosawazishwa na isiyolingana ni kuzingatia matokeo ya urejeshaji wa ajali:

• Sawazisha. Mtumiaji akikumbana na hitilafu akiwa amezuiwa wakati huduma inaendeshwa, haiwezi kuunganisha tena kwenye huduma hiyo baada ya kuwasha upya, hivyo jibu litapotea. Mtumiaji lazima arudie ombi na kutumaini kuwa hakuna dharura;
• Asynchronous. Mtumiaji akipatwa na dharura anaposubiri jibu la ombi, baada ya kuwasha upya mtumiaji anaweza kuendelea kusubiri jibu, kumaanisha kuwa jibu halipotei.

Kushindwa kupona sio tofauti pekee kati ya simu zinazolingana na zisizo sawa, lakini ikiwa unajaribu kuamua mtindo wa simu maalum inayotumiwa, kuangalia urejeshaji wa ajali itasaidia kufanya hivyo.

Sasa kwa kuwa unajua jinsi ya kuchagua chaguo la mwingiliano wakati wa kupiga huduma, hebu tuangalie chaguo za kuunganisha mtumiaji kwa mtoa huduma. Mtumiaji anaweza kuchagua chaguzi zifuatazo za unganisho:

1. Simu ya moja kwa moja ya synchronous;
2. Simu ya kusawazisha kupitia mpatanishi (dalali);
3. Simu ya Asynchronous kupitia mpatanishi (dalali).

Nitazingatia kila chaguo tofauti

Simu ya moja kwa moja inayosawazishwa

Njia ya simu ya SOAP juu ya huduma ya Wavuti ya HTTP ni ya moja kwa moja: sawa na simu ya kazi, mtumiaji anajua anwani ya mwisho na anaiita moja kwa moja. Kwa simu iliyofanikiwa, huduma ya Wavuti lazima ifanye kazi wakati mtumiaji anapiga simu ya mwisho na lazima ijibu kabla ya mtumiaji kuisha. Ikiwa huduma ya Wavuti itatumwa kwa eneo jipya (kwa mfano, kikoa tofauti cha Mtandao), mtumiaji lazima aarifiwe kuhusu URI mpya ya mwisho. Wakati wa kupeleka watoa huduma wengi wa aina moja, mwisho wa kila mtoa huduma lazima uwe na URI tofauti. Ili kuchagua mtoa huduma maalum, mtumiaji lazima ajue kila URI kama hiyo.

Kwa mfano, fikiria bei rahisi ya huduma ya Wavuti: mlaji hupita katika alama ya hisa na kupokea thamani yake ya sasa. Huduma kama hiyo inaweza kutolewa na kampuni tofauti za wakala, ambayo kila moja itakuwa na URI yake. Kupata URI ya huduma ya Mtandao ni tatizo la kuku na yai. Ikiwa mtumiaji alijua eneo la mwisho, inaweza kuomba anwani ya huduma, lakini anwani hiyo ni nini ni jambo ambalo mtumiaji lazima ajue kabla ya kuomba anwani.

Ili kutatua tatizo hili, kuna maelezo ya Universal Description Discovery and Integration (UDDI) ambayo inaelezea huduma ya Wavuti ambayo ni saraka (sawa na kitabu cha simu) kwa ajili ya kutafuta huduma nyingine za Wavuti. Wazo ni kupeleka huduma ya UDDI kwa anwani ambayo inajulikana kwa watumiaji; mtumiaji anaweza kutumia UDDI kupata huduma zingine za Wavuti.

Katika hali ya huduma ya bei ya hisa, mtumiaji anajua anwani ya huduma ya UDDI, ambayo pia inajua anwani za huduma za bei ya hisa (ona Mchoro 1).

Kielelezo cha 2 kinaonyesha jinsi mtumiaji anavyotumia huduma ya UDDI kupata mwisho wa watoa huduma wa bei ya hisa na kumpigia simu mmoja wao. Mchakato unafuata algorithm ifuatayo:

1. Mtumiaji anaomba orodha ya watoa huduma kutoka UDDI;
2. Mtumiaji huchagua mwisho wa mtoa huduma kutoka kwa orodha iliyopatikana kutoka kwa UDDI;
3. Mtumiaji huita mwisho huu.

Ninaona kuwa algorithm ya kuchagua mtoaji kabisa inategemea watumiaji; katika mfano huu, mtumiaji anachagua tu ya kwanza kwenye orodha. Katika hali halisi, chaguo hili linaweza kuwa ngumu zaidi.

Pia nitakumbuka kuwa kwa vile mwisho wa huduma unaweza kubadilika, kila wakati mtumiaji anataka kupiga huduma, lazima aulize tena UDDI na kuangalia ikiwa maelezo ya mtoa huduma yamebadilika. Kulazimika kufanya ombi la UDDI kwa kila simu ya huduma huleta taarifa ya ziada, hasa katika hali ya kawaida ambapo taarifa za mtoa huduma hazibadiliki.

Simu inayosawazishwa kupitia mpatanishi

Ubaya wa simu ya moja kwa moja ni kwamba mtumiaji anahitaji kujua URI ya kituo cha mwisho cha mtoa huduma ili kupiga huduma. Inatumia UDDI kama saraka kutafuta URI hii. Ikiwa kuna watoa huduma wengi, UDDI ina URI nyingi na mtumiaji lazima achague mmoja wao. Ikiwa mtoa huduma atabadilisha URI ya mwisho, ni lazima ijisajili upya na seva ya UDDI ili UDDI ihifadhi URI mpya. Mtumiaji lazima aombe tena UDDI ili kupata URI mpya. Kimsingi hii inamaanisha kuwa kila wakati mtumiaji anapotaka kutumia huduma, lazima aulize UDDI ya URI za sehemu za mwisho na kuchagua mojawapo. Hii husababisha juhudi kubwa kwa mtumiaji wakati wa shughuli za mara kwa mara za kuuliza UDDI na kuchagua mtoaji. Mbinu hii pia inamlazimisha mtumiaji kuchagua mtoa huduma kwa namna fulani, labda kutoka kwenye orodha inayolingana.

Njia moja ya kurahisisha tatizo ni kutambulisha wakala ambaye anafanya kazi kama kati wakati wa kupiga huduma ya Wavuti. Mtumiaji haiiti tena huduma ya mtoa huduma moja kwa moja, lakini badala yake huita huduma ya wakala, ambayo nayo huita huduma ya mtoa huduma. Mtumiaji lazima ajue URI ya sehemu ya mwisho ya huduma ya proksi na kwa hivyo atumie UDDI kutafuta anwani, lakini katika hali hii, UDDI hurejesha URI moja pekee na si lazima mtumiaji afanye chaguo. Mtumiaji anaweza hata asijue kuwa sehemu ya mwisho ni huduma ya wakala; inajua tu kwamba inaweza kutumia URI hii kupiga huduma ya Wavuti. Dalali huunganisha mtumiaji na watoa huduma (ona Mchoro 3).

URI ya huduma ya proksi lazima iwe thabiti: baada ya mtumiaji kutumia UDDI kupata huduma ya proksi ya URI kwenye simu ya kwanza kwa huduma, mtumiaji anaweza kutumia tena URI hiyo kwa simu zinazofuatana (angalau hadi huduma ya proksi ikome kufanya kazi). Wakati huo huo, huduma ya proksi hufuatilia watoa huduma, URIs zao (zinazoweza kubadilika kati ya simu), upatikanaji wao (ikiwa simu ya mwisho ilishindwa), mzigo wao (simu ya mwisho ilichukua muda gani), nk. Huduma ya proksi inaweza kuchukua jukumu la kuchagua mtoa huduma bora kwa kila simu, na kumwondolea mtumiaji mzigo huu. Mtumiaji huita tu huduma sawa ya wakala kila wakati, na inaratibu na watoa huduma mbalimbali.

Mchoro wa 4 unaonyesha jinsi mtumiaji anavyotumia wakala wakati wa kupiga huduma. Algorithm ya uendeshaji ni kama ifuatavyo:

1. Mtumiaji anauliza UDDI kwa orodha ya watoa huduma. URI iliyorejeshwa kutoka UDDI kwa kweli ni huduma ya wakala. UDDI itarejesha URI moja tu, sio nyingi, kwa sababu wakala ana huduma moja tu ya wakala kwa huduma yoyote;
2. Mtumiaji huita huduma kwa kutumia URI ya wakala;
3. Huduma ya wakala huchagua mtoa huduma kutoka kwenye orodha ya watoa huduma wanaopatikana;
4. Huduma ya wakala huita sehemu ya mwisho ya mtoaji aliyechaguliwa.

Tafadhali kumbuka kuwa wasiwasi wa kuchagua mtoaji umeondolewa kutoka kwa watumiaji - chaguo hili linatekelezwa katika huduma ya wakala wa wakala. Hii hurahisisha maisha ya watumiaji. Baada ya yote, mchakato wa uteuzi katika huduma ya wakala hauwezi kuwa tofauti na mchakato unaotumiwa na mtumiaji. Hata hivyo, kwa kuwa seva ya UDDI na huduma ya proksi imeambatanishwa katika wakala, utendakazi fulani unaweza kutekelezwa kwa urahisi, kama vile kuweka akiba ya maelezo ya UDDI na kupokea arifa kutoka kwa seva ya UDDI hadi kwa huduma ya proksi kwamba taarifa iliyoakibishwa si ya sasa tena.

Kumbuka pia kwamba kwa kuwa anwani ya proksi ni thabiti, si lazima mtumiaji aendelee kuuliza UDDI kwa kila simu ya huduma. Hiyo ni, mtumiaji anahitaji tu kuomba UDDI mara moja, kisha kache anwani ya huduma ya wakala na uitumie kwa simu zinazorudiwa kwa huduma. Hii inapunguza kwa kiasi kikubwa malipo ya juu wakati wa kupiga huduma.

Simu ya Asynchronous kupitia proksi

Hasara ya mbinu ya synchronous ni kwamba mtumiaji lazima asubiri huduma ikamilike - thread lazima izuiwe wakati huduma inaendesha. Ikiwa huduma inaendesha kwa muda mrefu, mtumiaji anaweza kuacha kusubiri jibu. Wakati mtumiaji anaomba ombi (na ikiwa hakuna watoa huduma wanaofanya kazi au wamejaa kupita kiasi), haiwezi kusubiri. Na, kama ilivyotajwa hapo juu, ikiwa mtumiaji atapata dharura wakati wa kufungia kazi, hata baada ya kuwasha upya, jibu litapotea na simu itahitaji kujaribiwa tena.

Suluhisho la kawaida kwa tatizo hili ni kwa mtumiaji kuita huduma kwa njia isiyo sawa. Kwa njia hii, mtumiaji hutumia thread moja kutuma ombi na pili kupokea majibu. Hiyo ni, walaji si lazima kuzuia kazi wakati akisubiri jibu na anaweza kufanya kazi nyingine wakati huo huo. Kwa hivyo, mtumiaji ni nyeti sana kwa maisha ya huduma ya mtoa huduma.

Dalali, ambayo inaruhusu mtumiaji kuomba huduma ya Wavuti kwa usawa, inatekelezwa kwa kutumia mfumo wa ujumbe unaotumia foleni za ujumbe kutuma ombi na kupokea jibu. Sawa na huduma ya seva mbadala iliyosawazishwa, jozi ya foleni za ujumbe hufanya kama anwani moja ambayo inatumiwa na mtumiaji kuomba huduma, bila kujali idadi ya watoa huduma wanaoweza kusikiliza (ona Mchoro 5).

Mbinu hii hutumia muundo wa Ombi-Jibu ili kuomba huduma ya Wavuti. Badala ya itifaki ya HTTP iliyobainishwa katika WS-I BP 1.1, vipengele vya usafiri sasa vinaweza kutekeleza foleni za ujumbe. Ombi la SOAP na majibu ni sawa na WS-I BP, lakini zimefungwa katika ujumbe wa mfumo wa ujumbe.

Kielelezo cha 6 kinaonyesha jinsi mtumiaji anavyoomba huduma kwa usawa kwa kutumia wakala kwa kutumia kanuni ifuatayo:

1. Mtumiaji hupitisha ombi la SOAP kama ujumbe kwa foleni ya ombi. Mtumiaji anamaliza kazi yake na anaweza kutumia thread kufanya kazi nyingine;
2. Kila mtoaji ni mtumiaji wa foleni ya ombi, na kuwafanya watumiaji washindani. Mfumo wa utumaji ujumbe huamua ni mtoa huduma gani anaweza kupokea ujumbe na kuhakikisha kwamba ni mtoa huduma mmoja tu anayeupokea. Jinsi hii inavyofanya kazi inategemea utekelezaji wa mfumo wa ujumbe;
3. Mtoa huduma aliyeshinda anapokea ujumbe kutoka kwa foleni ya ombi;
4. Mtoa huduma anafanya huduma;
5. Mtoa huduma hutuma jibu la SABUNI kama ujumbe kwa foleni ya majibu. Mtoa huduma sasa anamaliza kazi yake na anaweza kutumia thread yake kwa kazi nyingine (kwa mfano, kusubiri ombi linalofuata);
6. Uzi wa watumiaji wanaosikiliza hupokea ujumbe ulio na jibu la SABUNI.

Tafadhali kumbuka kuwa kipengele cha kuchagua mtoa huduma sasa kinatekelezwa katika mfumo wa utumaji ujumbe, hivyo kurahisisha maisha kwa mtumiaji. Kumbuka pia kwamba ikiwa mtumiaji atapatwa na dharura baada ya kutuma ombi (na hata ikiwa jibu liko tayari kwa sasa), mfumo wa kutuma ujumbe utahifadhi jibu kwenye foleni ya majibu hadi mtumiaji atakapofanya kazi tena.

Pia nitatambua kuwa mtumiaji hatumii UDDI kutafuta foleni za maombi na majibu. Kwa sasa hakuna huduma ya kawaida ya kurejesha jozi ya anwani za foleni, kwa hivyo mtumiaji anahitaji tu kujua anwani. Wao ni ngumu-coded katika programu ya walaji au kusomwa nayo kutoka kwa faili ya usanidi. Katika siku zijazo, tunapaswa kupanua UDDI au kubainisha huduma sawa ambayo mtumiaji anaweza kuomba ili kufafanua jozi ya foleni ili kuomba huduma mahususi.

Sasa unajua chaguzi za aina za uunganisho kwa huduma za kupiga simu. Wacha tuangalie uwezo wa ziada wa ujumuishaji ambao unaweza pia kuwa muhimu, na kisha jinsi ya kuunda ESB ambayo hutupatia uwezo huu.

Chaguzi zingine za ujumuishaji

ESB pia hutoa uwezo wa kwenda zaidi ya simu za huduma na kuunganisha programu na sehemu za SOA kwa kutumia teknolojia zingine. Simu ya huduma karibu kila mara ni operesheni ya kuelekeza pande mbili, kumaanisha kwamba ombi hupitishwa kutoka kwa mtumiaji hadi kwa mtoa huduma na jibu hutumwa kwa upande mwingine. Teknolojia zingine za ujumuishaji hufanya kazi kama shughuli za unidirectional, ambapo mtumaji hutuma habari kwa mpokeaji na haingojei jibu; mpokeaji anapokea tu habari bila hitaji la jibu.

Uhamisho wa data

Wakati mwingine programu inahitaji tu kupitisha data kwa programu nyingine bila kuhitaji kupiga utaratibu wa mpokeaji na bila shaka bila kusubiri matokeo. Mtumaji hahitaji kumwambia mpokeaji nini cha kufanya na data; inafanya data hiyo kupatikana.

Simu ya huduma inaweza kutumika kuhamisha data, ambayo ni sawa na kupiga njia ya seta, lakini uhamishaji wa data unafanywa kwa kutumia kanuni ya RPC. Kwa uhalisia, uhamishaji wa data ni kama uhamishaji wa faili: data inatumwa na mtumaji na kuletwa na mpokeaji bila kumwambia mpokeaji anachopaswa kufanya na data hiyo. Huu unaonekana zaidi kama ujumbe wa SOAP wa mtindo wa hati kuliko ujumbe wa mtindo wa RPC.

Kutumia ESB kwa uhamisho wa data huongeza uwezo wa kupata mpokeaji na kuhamisha data kwa uaminifu. Mtumaji hahitaji kujua jinsi ya kupata mpokeaji, anahitaji tu kujua jinsi ya kupata ESB na kuiamini ili kupata mpokeaji. ESB pia inawajibika kwa uhamishaji wa data wa kuaminika. Mtumaji anaweza kusambaza data kwa ESB na kuwa na uhakika kwamba itahamishwa.

Maelezo ya ziada kuhusu teknolojia ya uhamishaji data yanaweza kupatikana katika kiolezo cha Ujumbe wa Hati (kwa maelezo zaidi kuhusu hili, angalia kitabu " ", kiungo ambacho kimetolewa katika sehemu "").

Arifa ya Tukio

Wakati mwingine mabadiliko katika programu moja yanahitaji kuarifiwa kwa programu zingine. Kwa mfano, ikiwa mtumiaji atabadilisha anwani yake katika programu moja, programu zingine zilizo na hifadhidata zao zinahitaji kuarifiwa ili ziweze kusahihisha rekodi zao.

Kwa mara nyingine tena, programu moja inaweza kuita huduma katika programu nyingine ili kuijulisha kuhusu mabadiliko, lakini kuna matatizo matatu na mbinu hii. Shida mbili za kwanza ni sawa na uhamishaji wa data. Kwanza, simu ya huduma ni maalum sana katika suala la kumwambia mpokeaji nini cha kufanya na habari, na pili, inaelekea kuwa ya pande mbili, na kumlazimisha mtumaji kusubiri jibu (hata kwa usawa), ambalo hataki kabisa. kufanya .

Suala la tatu na muhimu zaidi wakati wa kupiga simu kwa huduma kwa arifa ya tukio ni kwamba kupiga huduma kimsingi ni mchakato wa moja kwa moja, kutoka kwa mtumiaji hadi kwa mtoaji, wakati arifa ya tukio kimsingi ni mchakato wa moja kwa wengi. " , imekusudiwa wapokeaji wote wanaovutiwa. Kwa kutumia simu ya huduma, mtumaji atalazimika kufuatilia wapokeaji wote wanaovutiwa na kupiga huduma kwa kila mmoja wao kibinafsi. Utangazaji kama huo wa arifa ni bora kuachwa kwa wakala aliye kati ya mtumaji na wapokeaji.

Kutumia ESB kwa arifa ya tukio huongeza uwezo wake wa kudumisha orodha ya wapokeaji wanaovutiwa na kuhakikisha uwasilishaji wa arifa kwa kila mmoja wao. Huruhusu mpokeaji kutuma arifa mara moja pekee na kuwa na uhakika kwamba itawasilishwa kwa wapokeaji wote wanaovutiwa, bila kujali wao ni akina nani. Kwa sababu operesheni hii si ya mwelekeo mmoja, mtumaji anaweza kufanya kazi nyingine wakati arifa zinawasilishwa, na arifa zinaweza kuwasilishwa kwa sambamba.

Maelezo ya ziada juu ya teknolojia ya uhamishaji data yanaweza kupatikana katika kiolezo cha Ujumbe wa Tukio (tena, rejelea kitabu "Mifumo ya Ujumuishaji wa Biashara", iliyounganishwa katika sehemu ya " ").

Maendeleo ya Basi la Huduma ya Biashara

Sasa unajua tofauti kati ya kupiga huduma ya Wavuti ya mtoa huduma moja kwa moja na kutumia wakala kufanya hivyo. Pia umejifunza jinsi wakala anavyoweza kumruhusu mtumiaji kupiga huduma kwa usawazishaji au kwa njia isiyolingana.

ESB mara nyingi huitwa wakala. Kwa hivyo ESB inafaaje katika miundo na mifumo iliyoanzishwa?

Kujieleza na kugundulika

Kinachofanya huduma za Wavuti kuwa tofauti na mbinu zingine za ujumuishaji ni kwamba mtumiaji anaweza kuwasiliana kwa nguvu na mtoa huduma. Hii inafanikiwa kupitia utendaji kuu mbili zifuatazo:

• Kujieleza. Huduma ya Wavuti inajielezea kwa njia inayoweza kusomeka kwa mashine. Watoa huduma wawili au zaidi wa huduma sawa wanatambulika mara moja, hata kama wanatekelezwa kwa njia tofauti kabisa, kwa sababu violesura vyao vya maelezo vinalingana na maelezo sawa;
• Utambuzi. Watoa huduma za wavuti wanaweza kupangwa katika saraka zinazotunzwa kiotomatiki. Mtumiaji anaweza kuvinjari saraka kama hiyo ili kupata mtoaji wa huduma inayotaka.

Utendaji huu wa huduma za Wavuti ni tofauti sana na mbinu za ujumuishaji zilizopo. Ndani yao, miingiliano ilifafanuliwa wakati wa kukusanya na wakati wa mawasiliano kati ya watumiaji na watoa huduma. Miundo ya ujumbe haikuonyeshwa kwa maelezo. Yalitokana na makubaliano ya ndani na hayakuweza kutekelezwa kufuata muundo huu, na kusababisha mpokeaji kushindwa kuchakata muundo ulioundwa na mtumaji.

Uwezo wa kujieleza huduma za Wavuti umerahisisha ujumuishaji kwa kutangaza violesura ambavyo vilihitaji kufuatwa. Ugunduzi wa huduma zinazobadilika uliwaweka huru mtumiaji kutoka kuwa tegemezi kwa mtoaji mahususi kwa anwani mahususi, lakini uwezo huu ulizua matatizo yake yenyewe. Je, mtumiaji atafute watoa huduma mara moja au mfululizo?

Ilikuwa vigumu kusuluhisha mvutano kati ya kumshurutisha mteja kwa mtoa huduma mara moja na kwa wote kwa wakati wote na uwezekano wa kutafuta mtoa huduma mpya kwa kila simu wakati wa utekelezaji. ESB ilipendekeza chaguo la tatu, la maelewano - kumruhusu mtumiaji kuwasiliana kwa nguvu na huduma ya proksi mara moja na bado aweze kutumia watoa huduma wengi na watoa huduma wa siku zijazo kupitia huduma hiyo ya proksi.

Kwa hivyo, ESB haifanyi tu huduma kupatikana kwa watumiaji kupiga simu, lakini pia inatoa watumiaji uwezo wa kupata huduma kwa utaratibu.

Lango la Huduma

Msingi wa ESB iliyosawazishwa ni lango linalojulikana kama lango la huduma, ambalo hufanya kama mpatanishi kati ya watumiaji wa huduma na watoa huduma, kuwezesha usindikaji wa simu zilizounganishwa. Inatoa ufikiaji wa huduma zote zinazojulikana na huduma za wakala kwa kila moja yao. Kwa njia hii, lango hutoa "dirisha moja" kwa mtumiaji ambaye anataka kupiga huduma yoyote kutoka kwa mtoa huduma yeyote ambaye anajulikana kwa lango.

Ikiwa huduma ambazo lango huratibu ni huduma za Wavuti, basi zinajielezea. Kila huduma inatangaza kiolesura chake kwa kutumia WSDL, ambayo ina sehemu nne zifuatazo:

1. Aina za bandari- Seti ya shughuli zinazofanywa na huduma ya Wavuti. Aina ya bandari inaweza kuwa stockBrokerServices yenye bandari/shughuli kama getQuote .
2. Ujumbe- Umbizo la ombi na majibu, kama vile getQuoteRequest (ambalo lina alama ya hisa) na getQuoteResponse (ambalo lina bei).
3. Aina- Aina za data zinazotumiwa na huduma ya Wavuti, kama vile ishara na bei (au tu xs:string na xs:decimal).
4. Viunganishi- Anwani ya kupiga operesheni, kwa mfano, http://stockbroker.example.com/getQuote.

Huduma kama hizi za lango la Wavuti (au haswa huduma zao za wakala) pia zinaweza kugunduliwa. Lango hutoa uwezo huu kama huduma ya UDDI, kama ilivyojadiliwa hapo awali. Ili kupata anwani ya simu ya huduma, mtumiaji huuliza huduma ya UDDI ya lango kwa orodha ya watoa huduma kwa ajili ya uendeshaji unaohitajika wa WSDL na hupokea tena anwani ya huduma ya seva mbadala ya lango kwa ajili ya operesheni hiyo.

Basi la ujumbe

ESB isiyo ya kawaida inategemea muundo unaojulikana wa Basi la Ujumbe ulioelezewa kwenye kitabu " Violezo vya Ujumuishaji wa Biashara", iliyorejelewa katika "" sehemu. Basi la ujumbe ni mkusanyo wa njia za ujumbe (pia hujulikana kama foleni au mada), ambazo kwa kawaida husanidiwa kama jozi za kituo cha kujibu ombi. Kila jozi inawakilisha huduma inayoweza kutolewa na mtumiaji kwa kutumia basi. Mtumiaji huyu hupitisha ujumbe kwa foleni ya ombi la huduma na kisha (bila kulinganishwa) husikiliza foleni ya majibu ili kupata matokeo. Hujua ni matokeo gani yanayolingana na ombi lake mahususi kwa sababu matokeo yana kitambulisho sahihi cha uunganisho.

Mtumiaji anayepiga simu kwa huduma hajui ni nani anayetoa huduma hiyo. Watoa huduma pia wameunganishwa kwenye basi la ujumbe na kuisikiliza kwa ujumbe wa ombi. Ikiwa kuna watoa huduma wengi, wanashindana kama watumiaji kupokea ombi fulani. Mfumo wa ujumbe ambao basi la ujumbe hutekeleza hufanya kazi kama kidhibiti cha ujumbe na husambaza ujumbe wa ombi kwa watoa huduma, kwa namna fulani kuboresha usambazaji huu kulingana na salio la mzigo, ucheleweshaji wa mtandao, n.k. Mara tu mtoa huduma anapokea ombi, hutekeleza huduma na huweka matokeo katika ujumbe katika foleni ya majibu ya masharti. Hiyo ni, mtoa huduma na mtumiaji kamwe hawajui eneo la kila mmoja; wanajua tu kuhusu basi la ujumbe na anwani ya njia zinazolingana na wanaweza kuwasiliana kupitia njia za kawaida.

Basi hili la ujumbe ndio kiini cha ESB, na hakuna jipya hapa. Viunganishi vya programu vimetumia teknolojia hii kwa zaidi ya muongo mmoja, kwa kutumia bidhaa za kupanga foleni za ujumbe kama vile WebSphere® MQ na TIBCO Enterprise Message Service. Na kwa kweli, mara nyingi husemwa kwamba ikiwa unatumia bidhaa za ujumbe wa biashara, basi una ESB. Wateja wa IBM wamekuwa wakifurahia uwezo huu kwa muda na Wakala wa Ujumbe wa Ujumuishaji wa Biashara ya WebSphere na WebSphere MQ.

Kwa hivyo, je, ESB ni basi la ujumbe tu? Hapana, basi la ujumbe hakika ndio msingi wa ESB isiyolingana, lakini kuna zaidi kwa ESB kamili. ESB ina uwezo ambao basi la ujumbe halijawahi kuwa nao: uwezo wa kujieleza na ugunduzi uliotajwa hapo juu.

Basi bora la ujumbe

Kwa hivyo ikiwa basi la ujumbe sio ESB kamili, basi ESB hufanya nini kingine?

Ubaya wa teknolojia ya kawaida ya basi la ujumbe ni ukosefu wake wa uwezo wa kujieleza. Kwa mtazamo wa mtumiaji, kuna njia nyingi za kuomba huduma nyingi. Lakini ni ipi kati ya njia hizi zinazohitajika kwa mtumiaji kupiga huduma inayotakiwa? Mtumiaji hawezi tu kuwasilisha ombi kwa kituo chochote cha ombi; lazima ijue njia sahihi ya kutumia kupiga huduma fulani. Vinginevyo, anaweza kununua tiketi ya ndege badala ya kitabu anachotaka. Zaidi ya hayo, hata baada ya kubainisha (kwa namna fulani) chaneli sahihi (na chaneli ya kusikiliza ili kupata jibu), ni lazima mtumiaji ajue umbizo la data la kutuma ombi (na katika umbizo la data la kutarajia jibu).

Kama ilivyojadiliwa hapo awali, kwa huduma za Wavuti zilizosawazishwa shida hii hutatuliwa na WSDL, ambayo sasa ni lahaja ya kiwango cha kuelezea huduma za asynchronous pia. WSDL inayohusishwa na kituo cha ombi lazima ielezee huduma ambayo kituo hutoa, pamoja na muundo wa ujumbe wa ombi ambao mtumiaji lazima atoe. WSDL pengine pia inapaswa kubainisha njia ya majibu ambayo mtumiaji anapaswa kusikiliza ili kupokea jibu, na muundo wa ujumbe wa majibu unaotarajiwa. Kwa njia hii, programu ya kupiga simu inaweza kuchanganua kiprogramu jozi ya vituo vya ombi la huduma na kubaini kama vinatoa huduma inayotakikana kwa kutumia ombi linalohitajika na umbizo la ujumbe wa majibu.

Njia za huduma zinazojieleza huanzisha tatizo lingine, ambalo ni tatizo la ugunduzi, ambalo huduma za Wavuti zinazolingana hutatua na UDDI. Kama ilivyojadiliwa hapo awali, mtumiaji huuliza seva ya UDDI kwa anwani ya mtoa huduma wa Wavuti, na seva hurejesha URL ya mtoa huduma huyo. Mtumiaji hutumia URL hii kupiga huduma.

ESB inahitaji huduma sawa ya saraka iliyo na API inayofanana na UDDI ambayo mtumiaji anaweza kutumia kuuliza anwani ya huduma inayotekeleza utendakazi wa WSDL unaotaka. ESB inarudisha anwani ya jozi inayolingana ya ombi na njia za majibu. Hiyo ni, mteja wa ESB, sawa na mteja wa UDDI, hapaswi kujua chochote isipokuwa yafuatayo:

1. WSDL ambayo inaelezea huduma inayotaka kuombwa.
2. Anwani ya huduma ya saraka ya ESB (ambayo inaweza kutolewa kutoka kwa anwani ya mizizi ya ESB).

Hii inatosha kugundua ombi la huduma na njia za majibu na kuanza kupiga huduma. Kwa kuongezea, huduma hii ya saraka ni huduma nyingine inayotolewa na ESB, kana kwamba ndio huduma kuu ya kupata huduma zingine.

Inasawazishwa au isiyolingana?

Watumiaji wa huduma wanakabiliwa na chaguo bandia kati ya mitindo miwili ya mwingiliano: iliyosawazishwa au isiyolingana. Ili kutatua tatizo hili, ESB nyingi zitatumia aina zote mbili na zinaweza kutoa miundo miwili ya kupiga simu kwa huduma sawa. Katika kesi hii, mtumiaji, wakati akiomba anwani ya huduma, ataweza kupokea chaguo mbili: moja kwa mode ya synchronous, ya pili kwa hali ya asynchronous. Mtumiaji anaweza kuchagua mtindo wa kupiga simu unaomfaa zaidi. Bila kujali mfano, huduma sawa huendesha, ingawa mfano maalum wa mtoa huduma unaweza kutofautiana.

Hiyo ni, ESB ni bora kuliko basi la kawaida la ujumbe kwa sababu ESB pia hufanya huduma kujielezea na kutoa huduma ya saraka ya kutafuta huduma zingine. Hivi ndivyo wachuuzi wa bidhaa za ujenzi wa ESB hujitahidi kutoa.

Hitimisho

Kama umeona, huduma inaweza kuitwa kwa njia yoyote ifuatayo:

1. Moja kwa moja na synchronously;
2. Synchronously kupitia broker;
3. Asynchronously kupitia wakala.

Enterprise Service Bus ni wakala anayetumia ombi la huduma kwa njia zinazolingana na zisizolingana. Pia inaruhusu uhamishaji wa data na arifa za tukio kati ya programu. Husaidia watumiaji kupata watoa huduma na kudhibiti maelezo ya mwingiliano kati yao.

ESB iliyosawazishwa ni lango la huduma ambalo hufanya kazi kama mratibu mkuu wa huduma nyingi. Asynchronous ESB ni basi la ujumbe ambalo huduma zake pia zinaauni uwezo wa kujieleza na kutambulika wa huduma za Wavuti. Sasa kuna viwango na mifumo ya kutekeleza ESB iliyosawazishwa na basi la ujumbe linalowezesha ESB isiyolingana. Viwango vya ziada vinahitajika ili kutambua uwezo kamili wa ESB.

), ambayo hapo awali iliitwa Axelot Datareon ESB, imekusudiwa kujenga mazingira ya habari iliyosambazwa ya biashara. Bidhaa ya programu huhakikisha mwingiliano wa programu zote zilizounganishwa katika kituo kimoja, kuchanganya vyanzo vilivyopo vya habari na kutoa ubadilishanaji wa data kati kati ya mifumo tofauti ya habari.

Basi la huduma ya data ya shirika la Datareon ESB ni njia ya kuhakikisha uthabiti na ukamilifu wa upashanaji habari, kuongeza utendaji wa jumla wa mfumo wa habari na kupunguza gharama za kazi kwa usimamizi wake.

Bidhaa ya programu ya Datareon ESB imejumuishwa rasmi katika rejista ya umoja ya programu za Kirusi kwa kompyuta za elektroniki na hifadhidata, ambazo zinaweza kununuliwa na taasisi za serikali na manispaa.

Utendaji

• Inasaidia viwango mbalimbali na matukio ya ujumuishaji
• Dhibiti mazingira yako ya ujumuishaji na mfumo ikolojia wa Eclipse
• Mabadiliko ya data (algorithms ya mabadiliko ya data ya hatua nyingi na udhibiti wa hali anuwai)
• Hamisha data ya saizi yoyote (kuongeza wima na mlalo)
• Ujumuishaji rahisi na bidhaa kwenye jukwaa la 1C:Enterprise 8
• Kuhakikisha uhamisho wa data salama
• Uchunguzi na ufuatiliaji wa hali ya mtandao mzima wa usambazaji wa data

Matatizo ya kutatuliwa

• Uhamisho wa data kati ya mifumo tofauti ya habari (pamoja na uelekezaji au uhakika-kwa-uhakika)
• Uundaji wa nafasi moja ya habari katika mazingira tofauti
• Ujenzi wa mfumo uliosambazwa kulingana na modeli ya tukio katika chaguzi zifuatazo:
  • kujenga maombi na michakato ya biashara ya mwisho hadi mwisho kulingana na mfano wa tukio;
  • kuunda mfumo na maingiliano ya maombi ya biashara katika mifumo mbalimbali ya habari
• Kupata usanifu mbaya wa usimamizi wa kiwango cha biashara / umiliki
• Usambazaji wa mfumo wa kubadilishana data katika kiwango cha usafiri na katika kiwango cha mantiki ya biashara
• Kukabidhi kazi ya ujenzi wa habari hutiririka kwa idara za uchambuzi
• Kupunguza utata wa muundo wa ujumuishaji na kupunguza mahitaji ya upitishaji wa kituo
• Kuongezeka kwa utulivu wa jumla wa safu ya usafiri wa data
• Kupunguza gharama za ununuzi wakati wa kubadilishana data kati ya idara tofauti

2017

Axelot Datareon ESB 2.1.0.0

Suluhisho la AXELOT Datareon ESB lilijumuishwa katika orodha ya umahiri wa Maendeleo ya Maombi ya Dhahabu - ukweli unaothibitisha ubora wa juu wa bidhaa na utangamano wake na bidhaa za Microsoft.

AXELOT Datareon ESB hutoa idadi ya manufaa muhimu kwa biashara:

• Uwezekano wa kuunganishwa;
• Kuegemea na reusability ya rasilimali;
• Kupata usanifu wa usimamizi wa kiwango cha biashara/hodari;
• Kukabidhi kazi ya kujenga mtiririko wa habari kwa idara za uchambuzi;
• Kupunguza utata wa jumla wa mpango wa ushirikiano na kupunguza mahitaji ya upitishaji wa njia;
• Kuongeza utulivu wa jumla wa safu ya uhamisho wa data ya usafiri;
• Kupunguza gharama za manunuzi wakati wa kubadilishana data kati ya idara tofauti;
• Kupunguza gharama za jumla za kudumisha na kudumisha mfumo wa habari.

Vipengele kuu vya mfumo:

• Idadi kubwa ya viunganisho kwa mifumo mbalimbali: 1C:Enterprise 8, huduma za SOAP, huduma za REST, MS SQL, IBM DB2, Oracle DB, PostgreSQL, SharePoint, OData, TCP, Siemens TeamCenter na wengine;
• Utaratibu wa programu-jalizi wa kujiendeleza kwa viunganishi;
• Msaada kwa lugha na teknolojia mbalimbali za programu wakati wa kuendeleza hali za mwingiliano: 1C: Biashara 8, JavaScript, T-SQL;
• Kuweka matukio ya mabadiliko ya data ya hatua nyingi kwa kutumia mbinu za kuona ramani na mabadiliko maalum ya XSLT;
• Fanya kazi na miundo mbalimbali ya data (XML, JSON, XLS, DBF, CSV, Base64 na wengine);
• Uelekezaji thabiti na wa nguvu wa pakiti za habari;
• Kasi ya juu ya mwingiliano na uvumilivu wa makosa: mahitaji ya kupunguzwa kwa bandwidth ya mtandao, kusawazisha mzigo, kutengwa kwa vikoa vya habari, uwezo wa kufuatilia hali ya nodes za ushirikiano;
• Msaada kwa mfano wa tukio, simu za synchronous na asynchronous, utoaji wa uhakika;
• Kubadilisha hali za ujumuishaji za mifumo ya waliojisajili (upakuaji/upakiaji, ugeuzaji na taratibu za kuelekeza) katika hali ya "motomoto" bila hitaji la kuzizuia (ikiwa ni pamoja na usanidi kwenye jukwaa la 1C:Enterprise 8);
• Utambuzi na ufuatiliaji wa michakato yote ya ujumuishaji, uwezo wa kurekebisha na kufuatilia vifurushi vya habari.

Uangalifu hasa hulipwa kwa ujumuishaji wa programu kwenye 1C:Enterprise 8 jukwaa. Uwasilishaji unajumuisha mfumo mdogo maalum ambao unaweza kujengwa katika usanidi wowote wa kawaida kwenye jukwaa la 1C:Enterprise 8 na hutoa njia zote muhimu za usanidi wa haraka na rahisi na usimamizi wa ujumuishaji. Mwingiliano wa "AXELOT: ESB Service Data Bus" na usanidi kwenye jukwaa la "1C:Enterprise 8" unafanywa kupitia huduma za SOAP na REST.

Vipengele vya seva "AXELOT: ESB Service Data Bus" vinatengenezwa katika C ++. Utawala na usanidi wa "AXELOT: Basi ya Data ya Huduma ya ESB" inafanywa katika mazingira ya maendeleo ya Eclipse na inaweza kufanywa kwa kushirikiana na uundaji wa mifumo kwenye jukwaa la 1C:Enterprise 8 katika 1C:Zana za Ukuzaji wa Biashara. "AXELOT: ESB Service Data Bus" ina mifumo mingi na inasaidia mifumo ya uendeshaji ya MS Windows na Linux.

AXELOT Datareon ESB ni maendeleo ya Kirusi kabisa na iko katika mchakato wa kuingizwa katika rejista ya umoja wa mipango ya Kirusi kwa kompyuta za elektroniki na hifadhidata, ambazo zinaweza kununuliwa na taasisi za serikali na manispaa ili kutatua matatizo fulani.

Ujumuishaji wa mifumo ya habari kwa kutumia basi la huduma ya biashara (ESB)

Miongoni mwa mbinu bora zaidi za kuunganisha mifumo changamano ya taarifa ni ujenzi wa mart ya data yenye mantiki, pamoja na uundaji wa miundomsingi ya kubadilishana data kwa kutumia mifumo ya MDM na mabasi ya huduma za biashara (ESB, Enterprise Service Bus). Suluhu zetu, ikiwa ni pamoja na mfumo wa ArchiGraph.MDM, zinafaa kutumika kama sehemu ya mfumo wa uendeshaji wenye madhumuni maalum ya Astra Linux Special Edition, pamoja na Alt Linux.

Kwa nini basi ya kuunganisha inahitajika?

Kampuni yoyote inayotumia zaidi ya bidhaa mbili za programu zinazofanya kazi na seti zinazopishana za taarifa inajua gharama ya kutowasiliana kati yao. Orodha za wateja ambazo hazijaoanishwa au laini za bidhaa na maelezo mengine kati ya ERP, CRM na programu nyingine za shirika husababisha upotevu wa mara kwa mara wa muda, rasilimali na sifa ya kampuni. Suluhisho pekee sahihi la tatizo hili ni utekelezaji wa basi la huduma ya biashara (ESB), kwa kushirikiana na mfumo mkuu wa usimamizi wa data (MDM).

Suluhisho kulingana na upakiaji wa mara kwa mara na mabadiliko ya taarifa (ETL) na usanifu unaolenga huduma (SOA) hutoa tu suluhu la muda kwa matatizo hayo, yana hasara nyingi, na kupunguza uwezekano wa ukuaji wa miundombinu ya TEHAMA.

Utekelezaji wa basi ya kuunganisha

Wakati wa kutekeleza basi ya ushirikiano, kazi hutokea kwa ramani (kulinganisha) muundo wa habari kuhusu vitu sawa vilivyopo katika mifumo tofauti ya habari. Tatizo hili lazima litatuliwe kwa kuunda kielelezo cha maelezo ya jumla ambacho hakina upande wowote kuhusiana na kila programu. Mfano huo unaweza kutekelezwa kwa ufanisi zaidi kwa kutumia teknolojia za semantic. Kufikia matokeo bora ya utekelezaji kunahitaji muundo huo utengenezwe na mbunifu wa kitaalamu wa data.

Sehemu muhimu ya mradi wa utekelezaji ni utekelezaji wa viunganishi (interfaces za programu) kwa programu zote zinazohusika katika kubadilishana data. Wataalamu wetu wana uzoefu wa kuunda na kuunganisha viunganishi vya anuwai ya programu kwenye majukwaa anuwai.

Tunatekeleza miradi ya ujumuishaji pamoja na washirika kulingana na suluhu za IBM WebSphere MQ, Basi la Huduma ya Uunganishaji, Wakala wa Ujumbe wa WSO2, Apache Synapse, pamoja na basi la Semantiki za Biashara.

Mara nyingi, mradi wa kutekeleza basi ya ujumuishaji hufanywa kama sehemu ya urekebishaji wa jumla wa usanifu wa habari wa biashara.

2005

Basi la huduma ya ushirika - njia ya "bajeti" ya kutatua shida za ujumuishaji

Imetayarishwa: kulingana na nyenzo kutoka kwa tovuti za kigeni
Tafsiri: Intersoft Lab

Kuendelea kumjulisha msomaji mbinu mbalimbali za ujumuishaji, tuliamua kuzingatia teknolojia mpya na ya kuvutia sana - Enterprise Service Bus (ESB).

Basi la huduma ya biashara ni nini na linahusiana vipi na ujumuishaji wa maombi ya biashara (EAI) iliyojadiliwa katika matoleo ya awali ya Jarida la Klabu ya Wataalamu wa DWH, OLAP na XML? Kwa mujibu wa mila iliyoanzishwa, kwanza tutatoa sakafu kwa wataalam katika uwanja huu.

Wachambuzi wa Gartner wanafafanua ESB kama aina mpya ya vifaa vya kati vinavyochanganya utendakazi wa aina zingine zilizopo za vifaa vya kati. Enterprise Service Bus inasaidia huduma za Wavuti kwa kutekeleza SOAP (Itifaki ya Ufikiaji wa Kitu Rahisi) na kutumia WSDL (Lugha ya Maelezo ya Huduma za Wavuti) na UDDI (Maelezo ya Jumla, Ugunduzi na Muunganisho). Maelezo ya Jumla, Ugunduzi na Muunganisho). Mabasi mengi ya huduma za biashara pia yanaunga mkono mitindo mingine ya mawasiliano, ikijumuisha uwasilishaji wa uhakika na kuchapisha na kujisajili. Huduma zinazotolewa na mabasi haya hutoa "thamani iliyoongezwa" ambayo programu ya kati ya utumaji ujumbe nyepesi haitoi - uthibitishaji wa ujumbe, mabadiliko, uelekezaji kulingana na maudhui, usalama, ugunduzi wa huduma kwa usanifu unaolenga huduma, kusawazisha mzigo na usajili. Huduma zingine zimejengwa kwenye msingi wa basi, zingine zinatekelezwa kwenye moduli za kuziba. Kwa kuongeza, mabasi yanaunga mkono XML na miundo mingine ya ujumbe.

Ni nini kinachovutia kuhusu basi ya huduma ya ushirika? Awali ya yote, nafuu yake ya jamaa. Bidhaa za ESB kawaida huwekwa kama bei nafuu, au, kama wanasema, suluhisho la "bajeti".

Hakika, leo kuna mahitaji ya kuongezeka kwa teknolojia ya ushirikiano. Ingawa utumaji wa EAI ulikuwa unahusu malengo ya kimkakati na hivyo kulipwa kwa muda mrefu, changamoto ambazo kampuni sasa zinakabili ni za kimbinu na zinahitaji mbinu mpya. "Uhalisia wa Kisasa wa Biashara" umeleta uangalizi kwa maeneo ambayo wachuuzi wa EAI wamekuwa dhaifu kimapokeo—mabadiliko, uchakataji wa programu zinazozingatia msanidi programu (kama vile Java), na ujumuishaji na teknolojia za nje. Hii yote "iliyoandaliwa ardhi yenye rutuba" kwa kuibuka kwa kitengo kipya cha bidhaa - ESB.

Kuzungumza juu ya sifa za basi la huduma ya biashara, inafaa kunukuu maneno ya makamu wa rais na mjumbe wa idara ya utafiti ya Gartner Roy Schulte: "Mitandao ya kati ya kawaida haiwezi tena kuunga mkono programu mpya zinazotumia huduma zinazoelekezwa (Usanifu Mwelekeo wa Huduma, abbr. SOA) na usanifu unaoendeshwa na matukio (EDA), Huduma za Wavuti na usimamizi wa mchakato wa biashara. Hii ndiyo sababu kuu kwa nini wasanifu na wasimamizi wa mifumo ya habari wanapaswa kuimarisha miundomsingi ya taarifa za biashara zao na ESBs.

Mchambuzi mkuu wa Gartner anaangazia vikundi vya wachuuzi wa ESB. Anajumuisha bidhaa za ESB katika kundi la kwanza, ambazo zimewekwa kama masuluhisho ya ujumuishaji ya "bajeti" ambayo yanafaa kabisa kwa ajili ya kuunga mkono maombi ya mchanganyiko na SOA. Kundi la pili linajumuisha bidhaa zilizokusudiwa kwa soko la huduma za Wavuti, na mwishowe, za mwisho ni zana za programu ambazo hutoa msaada wa EDA. Roya Schulte anakadiria kuwa soko la ESB litaimarika zaidi ya miaka ijayo, likiendeshwa na ongezeko la mahitaji ya huduma za Wavuti na suluhu za itifaki nyingi na zinazoendeshwa na matukio.

Inafurahisha kwamba katika idadi ya makampuni ESB inachukuliwa sio kama kitengo cha bidhaa, lakini kama usanifu. Kwa mfano, katika IBM, basi la huduma ya biashara linachukuliwa kuwa "mfano wa usanifu."

Kwa hivyo, inaweza kusemwa kuwa bado hakuna ufafanuzi wazi wa ESB ni nini. Kwa kweli, mjadala unahusu maswali mawili:

1. Je, ESB ni usanifu (na ambao hauhitaji hata kusawazishwa), "njia ya njia moja" au bidhaa inayojitegemea.

   Ingawa inaweza kuwa na manufaa kwa baadhi ya wachuuzi ambao kwa sasa hawana suluhu iliyotayarishwa tayari kuzungumza kuhusu Enterprise Service Bus kama usanifu, mazingira ya sasa ni kwamba wateja wanahitaji utendakazi wa ESB kujumuishwa katika matoleo ya bidhaa zao. Kwa hivyo, tunapaswa kutarajia kuona ongezeko la idadi ya wachuuzi wanaotoa uwezo wa ESB katika kipindi cha miaka miwili ijayo.

2. Je, ni mahali gani na mustakabali wa bidhaa za ESB, yaani, Enterprise Service Bus ni mfumo wa hali ya juu zaidi wa kupanga foleni wa ujumbe, unaotoa mabadiliko rahisi ya XML, pamoja na uelekezaji na utumaji ujumbe, au utumizi wa adapta za programu, uundaji otomatiki na uundaji wa mchakato wa biashara utaruhusu ESB ili kuchukua nafasi ya EAI kwa mafanikio.

Kwa sasa, hakuna majibu ya uhakika kwa maswali haya.

Walakini, inafaa kusisitiza kwamba ingawa kuna ukosefu wa uwazi kuhusu basi la huduma ya biashara, ni wazi kuwa kwa sababu ya ukweli kwamba ESB inategemea viwango vya wazi, inaweza kupunguza kwa kiasi kikubwa gharama za ununuzi na utekelezaji.

Kumbuka kwamba neno "huduma" katika neno "basi ya huduma ya shirika" ni kuu. Kwa hivyo, wachambuzi wa Utafiti wa Forrester wanaona ESB kama "safu ya vifaa vya kati ambavyo vinaweza kutumika kufikia seti ya huduma za biashara za msingi (zinazoweza kutumika tena). SOA inaruhusu utendakazi mwingi kufichuliwa kama "huduma" kwenye basi la huduma ya biashara ambalo hupeleka mbele, kubadilisha, na kuthibitisha uingizaji na utoaji wa XML kutoka kwa huduma hizo.

ESB na XML

Itakuwa sio haki ikiwa hatungesisitiza jukumu maalum la XML - XML ​​ndio msingi wa ujumuishaji. Ukikubali kwamba XML ni zaidi ya "alfabeti" kuliko lugha tu, itakuwa wazi kwamba utekelezaji kamili wa ujumuishaji unahitaji kupanga michakato ya biashara, kudhibiti mabadiliko ya XML, na kuhalalisha na kusambaza ujumbe wa XML katika shirika lote. Utendaji huu wote ni msingi wa Basi la Huduma ya Biashara.

XML inaweza kutoa uwakilishi wa kina wa seti ya data. Umaarufu wa lugha hii unaweza kuelezewa na unyumbufu wake wa juu na upanuzi. Hakika, sintaksia ya XML hukuruhusu kusasisha na kuendeleza miundo maalum ya XML ili kushughulikia data mbalimbali.

Wakati huo huo, ukuaji wa haraka wa kiasi cha data kuhamishwa huleta shida kubwa kwa utendaji wa muundo wa habari wa shirika. Kwa hiyo, miradi ya kwanza ya ushirikiano ambayo ilitumia uwezo wa XML ilikuwa "hai" ushahidi wa ahadi ya lugha hii, lakini sasa kuna matatizo fulani na ongezeko la idadi, ukubwa na utata wa nyaraka za XML. Sababu kuu za shida zilizopo (ukosefu wa scalability) zimeorodheshwa hapa chini:

• Kuchanganua hati nzima: Kwa kawaida ungependa kuchanganua hati nzima, hata kama unahitaji tu kutoa sehemu yake kwa kuelekeza na kuchuja. Ikiwa nyaraka zinakuwa kubwa, muda wa kusubiri huongezeka.
• Changanua upya. Nyaraka mara nyingi huchanganuliwa - katika kila hatua ya mchakato wa biashara, kwa maneno mengine, nyaraka sawa zinaweza kupigwa mara kadhaa. Kwa sababu zoezi hili linatumia rasilimali nyingi sana, linashusha utendakazi na matokeo.
• Ubunifu wa nyuzi moja. Katika kesi hii, hatua inayofuata ya usindikaji haiwezi kuanza mpaka moja ya sasa imekamilika; kwa sababu hiyo, muda wa kusubiri unaongezeka kwa sababu mchakato mzima unategemea hatua ya polepole zaidi.

Ili kukabiliana na ukosefu huu wa scalability, inashauriwa kutumia usanifu wa usindikaji unaounga mkono vipengele vifuatavyo:

• Utiririshaji wa hati - huhakikisha kuwa hati za XML zinachakatwa kila kipengele kinapofika, i.e. muda mdogo wa kusubiri unahakikishwa. Mbinu hii inaruhusu ujumbe mkubwa kuchakatwa kwa tija kama ndogo.
• Uchakataji mahususi, ambao hupata faida kubwa sana za utendakazi kwa kuchakata sehemu muhimu pekee badala ya hati nzima ya XML.
• Uchakataji wa nyuzi nyingi, ambapo kichakataji hudhibiti upangaji wa hatua zinazofuatana kando ya chaneli, utekelezaji sambamba wa hatua za mtu binafsi, na kusawazisha upakiaji wa hatua zinazofanana wakati wa kuchakata vipande vingi vya XML.
• Skanning pekee ambayo, badala ya usomaji wa mara kwa mara wa muundo wa waraka huo tangu mwanzo, vipande vyote muhimu vinatolewa kwa uhamisho mmoja.

Kazi zilizo hapo juu zinaweza kutekelezwa kwa kutumia Basi ya Huduma ya Biashara - bila kuweka msimbo au usanidi maalum.

Kuna tofauti gani kati ya basi la huduma ya biashara (ESB) na madalali wa ujumbe (kwa mfano RabbitMQ)?

Matokeo yake, tatizo la utendaji usioridhisha linaweza kutatuliwa.

Hitimisho

Kwa kuzingatia machapisho katika machapisho ya mtandao wa kigeni na tathmini za wachambuzi kutoka kwa makampuni mashuhuri ya utafiti, basi la huduma za shirika si teknolojia mpya tu yenye uwezo mkubwa. Kwa hakika, Gartner anatabiri kwamba kufikia 2005, makampuni mengi makubwa yatakuwa yanatumia ESBs. IDC inaamini kuwa basi la huduma za shirika linapaswa "kubadilisha" teknolojia ya habari na kufanya usindikaji wa data unaosambazwa unaonyumbulika na hatari.

Hakika, usaidizi wa viwango vya wazi (na hasa XML) huruhusu ufumbuzi wa gharama nafuu lakini ufanisi na unahakikisha kurudi kwa haraka kwa uwekezaji, yaani ROI ya juu. Kama Steve Craggs, makamu wa rais wa Muungano wa Ushirikiano, anavyobaini, "ESB ndio msingi wa ujumuishaji, kutoa mazingira rahisi na yanayowezekana ambayo inaruhusu miradi ya ujumuishaji kutekelezwa kwa matunda, kwa mafanikio na kwa utaratibu."

Na bado, kutokuwa na uhakika juu ya utata wa neno "basi ya huduma ya shirika" bado kunabaki. Leo, ESB inarejelea teknolojia yoyote inayohitajika kutekeleza SOA. Huu ndio mtazamo unaoshikiliwa na ZapThink, kampuni inayobobea katika ukuzaji na utumiaji wa usanifu unaozingatia huduma. Kuhusiana na hili, wachambuzi wa ZapThink wanaonya kwamba isipokuwa ufafanuzi halisi na halisi wa basi la huduma ya biashara hautatengenezwa mnamo 2005, neno ESB "itatoweka milele kutoka kwa leksimu ya SOA." Kuhusu SOA yenyewe, itajadiliwa katika makala inayofuata.

Machapisho

1. Beth Gold-Bernstein, Je, ESB Ni Muhimu kwa Mustakabali Wako?
2. Nigel Thomas na Warren Buckley, "The Rise of the ESB."
3. Nyenzo zilizochapishwa kwenye tovuti ya Muungano wa Ushirikiano.

ESB na SOA ni nini

Maelezo bora ya mfumo wa kufikiri wa mfumo
Nick Coghlan, Msanidi programu wa Core Python

Inapatikana pia ndani Kikatalani, Deutsch, Kiingereza, Kifaransa, kiitaliano, Uholanzi, Português, Türkçe na 中文 .

Kifupi ESB na SOA inayohusishwa inaweza kuwa chanzo cha mkanganyiko. ESB inasimama kwa Enterprise Service Bus. SOA - Usanifu Mwelekeo wa Huduma.

Majina haya hayasemi mengi, kwa hivyo hapa chini ni habari kamili zaidi kwa lugha rahisi, bila lugha ya ushirika isiyo ya lazima.

ukweli wote

Hebu tufikirie nini kinatokea unapoingia kwenye ombi la mwisho la benki yako:

1. Jina lako limeonyeshwa
2. Salio la akaunti yako linaonyeshwa
3. Inaonyesha kadi zako za mkopo na benki
4. Kunaweza kuwa na orodha ya fedha zako za pamoja
5. Pia unapokea orodha ya mikopo iliyolipwa mapema ambayo unaweza kuvutiwa nayo

Kwa uwezekano wa hali ya juu, tunaweza kusema kwamba taarifa hizi zote ni za mifumo na programu mbalimbali, ambayo kila moja hutoa data kupitia aina fulani ya kiolesura (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV au nyingine yoyote. ):

1. kutoka kwa CRM inayoendesha Linux na Oracle
2. kutoka kwa mfumo wa COBOL unaoendeshwa kwenye mfumo mkuu wa z/OS
3. wanasema habari hii ilitoka kwa mfumo mkuu, lakini hawa jamaa wana midomo mikali sana kusema chochote isipokuwa kwamba wanapendelea CSV kuliko kila kitu kingine.
4. kutoka kwa mchanganyiko wa PHP na Ruby inayoendesha kwenye Windows
5. kutoka PostgreSQL, Python na Java inayoendesha Linux na Solaris

Swali ni jinsi gani unaweza kupata maombi ya mbele ya kuzungumza na mifumo 1-5? Naam, hakuna njia.

Huu ni msingi wa kimsingi wa kuhakikisha kuwa mazingira kama haya yanaweza kuwa zaidi ya mifumo mingi. Huwalazimishi kuwasiliana moja kwa moja.

Katika mchoro ulio hapa chini, kila simu kwa huduma inayotolewa na mfumo mwingine inawakilishwa na mstari wa unene na mtindo tofauti:

Kumbuka hata hatujaonyesha mchakato wowote wa kiwango cha juu (App1 inapiga simu kwa App2 na ama App3 au App5, kulingana na kama jibu la awali kutoka kwa App6 lilifaulu, ili App4 iweze kuchukua data ambayo ilitolewa na App2 baadaye, lakini ikiwa tu App1 haikatazi hii, nk).

Pia, kumbuka kuwa hatuzungumzii juu ya seva - kila moja ya mifumo inaweza kukimbia kwenye seva 10 za kimwili, hivyo angalau vipengele 60 vya kimwili vitabadilishana habari na kila mmoja.

Hata hivyo, baadhi ya masuala yanaonekana.

Jinsi ya kutenganisha miingiliano? Jinsi ya kupanga kupakua? Je, unaratibu vipi masasisho au muda wa chini uliopangwa wakati kila programu inadhibitiwa na timu tofauti za wasanidi programu, wachuuzi au idara na nusu ya wasanidi programu asili tayari wameondoka kwenye kampuni?

Ikiwa unafikiri unaweza kudhibiti programu 6, vipi kuhusu 30?

Je, unaweza kushughulikia 400? Na tangu 2000? Kila programu inaweza kuwa mfumo wake wa kipekee wa ikolojia, unaohitaji seva nyingi au vifaa vingine kuendeshwa, kwa hivyo ni sehemu 20,000 zinazosonga zilizoenea katika mabara yenye kila aina ya mipaka ya kiufundi na kitamaduni. Na sehemu hizi zote mara kwa mara na bila kukoma zinataka kubadilishana ujumbe kila wakati bila wakati wa kupumzika, hata kidogo. (Tutakuepusha na mchoro.)

Kuna jina kubwa kwa hali hii: machafuko.

Unawezaje kuboresha hali hiyo?

Hatua ya kwanza ni kukiri kwamba hali iko nje ya udhibiti. Hii inakuwezesha kutafuta suluhisho bila kujisikia hatia sana. Sawa, ilifanyika, haukujua jinsi ya kufanya vizuri zaidi, lakini kuna nafasi kwamba yote haya yanaweza kurekebishwa.

Hii inaweza kuleta mabadiliko ya shirika katika njia ya TEHAMA, lakini hatua nyingine ni kukumbuka kuwa mifumo na programu zimeundwa kwa zaidi ya kushiriki data tu. Zimeundwa kusaidia michakato ya biashara, bila kujali biashara yenyewe, iwe benki, kurekodi sauti, vifaa vya rada, chochote.

Mara tu pointi hizi mbili zimefafanuliwa wazi, unaweza kuanza kuunda au kuunda upya mifumo yako karibu na huduma.

Huduma ni kitu cha kufurahisha, kinachoweza kutumika tena na cha atomiki ambacho huonyeshwa na mfumo mmoja kwa programu zingine zinazotaka kuitumia, lakini huduma haifichuliwi moja kwa moja kwa mtindo wa moja kwa moja. Haya ndiyo maelezo mafupi na yenye maana zaidi iwezekanavyo.

Ikiwa utendakazi wa mfumo fulani unakidhi mahitaji haya matatu:

• I kuvutia (kuvutia)
• R inaweza kutumika (inaweza kutumika tena)
• A tomic (atomiki)

basi kuna nafasi nzuri kwamba mfumo unaweza na unapaswa kuonyeshwa kwa mifumo mingine kama huduma, lakini kamwe usiunganishwe moja kwa moja.

Hebu tujadili mbinu ya IRA kwa mifano michache.

Inaweza kubadilika	Vidokezo
Mazingira	Mfumo wa CRM wa kampuni ya umeme
Utendaji	Inarejesha orodha ya wateja ambao walikuwa wakitumia tovuti ya huduma binafsi mnamo Q3 2012
Hii inavutia?	Ndiyo, ya kuvutia kabisa. Hii inaweza kutumika kutengeneza kila aina ya ripoti na takwimu muhimu.
Inawezekana	Si, hakuna sana. Pamoja na ukweli kwamba hii inakuwezesha kuunda
mara nyingi	miundo ya hali ya juu kama vile takwimu za mwaka mzima,
kutumia?	Ni wazi kuwa hatutahitaji hii katika 2018.
Je, ni atomiki?	Pengine ndiyo. Ikiwa huduma zinazofanana tayari zipo kwa robo nyingine, basi itawezekana kutazama mwaka mzima.
Ninawezaje kugeuza hii kuwa IRA?	Lazimisha kupokea tarehe za kuanza na kumalizika kwa kipindi kiholela, badala ya kubainisha robo pekee. Lazimisha kupokea maombi kiholela, si lango pekee. Toa uwezo wa kubainisha programu ili kupokea taarifa kama kigezo cha ingizo.

Inaweza kubadilika	Vidokezo
Mazingira	tovuti ya e-commerce
Utendaji	Rejesha kila taarifa ambayo imewahi kukusanywa kwa mtumiaji aliyebainishwa
Hii inavutia?	Kwa ujumla, ndiyo. Ikiwa unaweza kufikia yote, unaweza kuchagua kila unachohitaji.
Inawezekana	Oddly kutosha, si kweli. Kutakuwa na wachache tu
mara nyingi	maombi, kama yapo, ambayo yatakuwa ya manufaa
kutumia?	tumia kabisa kila kipande cha habari.
Je, ni atomiki?	Bila shaka sivyo. Duru hii ya utendakazi inaelekea kuwa inaundwa kimantiki na kadhaa ya sehemu ndogo.
Ninawezaje kugeuza hii kuwa IRA?	Gawanya katika sehemu kadhaa ndogo. Fikiria juu ya kile kinachoelezea mnunuzi - wana anwani, nambari za simu, bidhaa zinazopendwa, njia zinazopendekezwa za kuwasiliana nao, na kadhalika. Kila moja ya pointi hizi inapaswa kugeuzwa kuwa huduma ya kujitegemea. Tumia ESB kuunda huduma za mchanganyiko kutoka kwa za atomiki.

Inaweza kubadilika	Vidokezo
Mazingira	Mfumo wowote wa CRM popote pale
Utendaji	Inasasisha safu wima ya CUST_AR_ZN katika jedwali la C_NAZ_AJ baada ya mtu kuunda akaunti
Hii inavutia?	Si ya kuvutia kabisa. Hii ni kazi ya ndani ya mfumo wa CRM. Hakuna mtu aliye na akili timamu ambaye angetaka kushughulika na utendaji wa kiwango cha chini kama hicho.
Inawezekana	Ndiyo, pengine. Akaunti inaweza kuundwa kupitia
mara nyingi	chaneli nyingi kwa hivyo inaonekana kama kitu mara kadhaa
kutumia?	kutumika.
Je, ni atomiki?	Inaonekana kuwa ndiyo. Hili ni sasisho rahisi kwa safu moja kwenye jedwali.
Jinsi ya kutengeneza kutoka
IRA hii?	Usijaribu hata kufanya huduma kutokana na hili. Haipendezi. Hakuna mtu anataka kufikiria juu ya safu wima na majedwali mahususi katika mfumo mmoja. Hii ni sehemu changamano ya mfumo wa CRM na, ingawa inaweza kutumika tena na atomiki, haifai kuunda huduma kutoka. Ni jukumu lako na CRM kulifikiria, usiwalazimishe wengine kulistahimili pia

Inaweza kubadilika	Vidokezo
Mazingira	Opereta wa rununu
Utendaji	Kuongeza kadi ya kulipia kabla katika bili
Hii inavutia?	Sana. Kila mtu anataka kuitumia, kupitia SMS, IVR, IM, lango, kadi za zawadi, n.k.
Inawezekana	Ndiyo. Inaweza kushiriki katika viwango vingi vya juu
mara nyingi	taratibu.
kutumia?
Je, ni atomiki?	Ndiyo, kutoka kwa mtazamo wa maombi ya kupiga simu, kadi inaweza kuongezwa au la. Ukweli kwamba bili hutekeleza hili kupitia mfululizo wa hatua sio muhimu. Kwa mtazamo wa biashara, hii ni ya atomiki; ni huduma isiyogawanyika inayotolewa na malipo.
Jinsi ya kutengeneza kutoka	Tayari ni IRA.
IRA hii?

Ikiwa umefanya programu yoyote katika miaka 50 iliyopita, itakuwa dhahiri kwako kwamba kutoa huduma ni sawa na kutoa API katika kipande kimoja cha msimbo hadi kingine. Tofauti pekee ni kwamba haushughuliki na submodules za mfumo mmoja, unafanya kazi katika kiwango cha mazingira yote ya mifumo ya mtu binafsi.

Upatikanaji wa huduma katika ESB na SOA¶

Sasa kwa kuwa unajua kwamba mifumo haiwasiliani moja kwa moja na unaelewa huduma ni nini, unaweza kuanza kutumia ESB kwa ufanisi.

Sasa ni kazi ya ESB kutoa na kuomba huduma za mifumo jumuishi. Kwa hivyo, katika hali nyingi, njia moja tu ya ufikiaji, kiolesura kimoja lazima kifafanuliwe kati ya kila mfumo na ESB.

Kwa hivyo ikiwa, kama kwenye mchoro hapo juu, unayo mifumo 8 - basi unayo miingiliano 16 (moja kwa kila mwelekeo) kwa uundaji, matengenezo, usimamizi na utoaji.

Bila ESB, ungekuwa na miingiliano 56 ya kuunda na kudhibiti (ikizingatiwa kila mfumo unazungumza na kila mwingine).

Hakuna violesura 40 vya ziada kunamaanisha kuwa kuna wakati mdogo uliopotea na pesa nyingi zimehifadhiwa. Hii ni sababu moja ya Ijumaa yako itakuwa chini ya dhiki.

Ukweli huu pekee unapaswa kukuhimiza kuzingatia kutekeleza ESB.

Ikiwa moja ya mifumo imeandikwa tena, kuhamishiwa kwa mmiliki mwingine, imegawanywa kati ya idara au wauzaji, basi itakuwa kazi ya wavulana wa ESB kufanya mabadiliko sahihi. Hakuna mifumo mingine hata itaona hili, kwani kiolesura chao kwa ESB hakitaguswa.

Mara tu unapoanza kupumua huduma za IRA mara kwa mara, unaweza kuanza kufikiria kuhusu huduma za kiwanja.

Je, unakumbuka huduma ya "nipe-chochote-unachoweza-kuhusu-huyu-mteja" iliyoangaziwa hapo juu?

Haikuwa wazo nzuri kuunda moja, lakini wakati mwingine utakutana na programu za mteja zinazohitaji kujumlisha maelezo. Vijana wa ESB watawajibika kwa hili, ambao kazi yao itakuwa kuchagua huduma bora za atomiki ili kuunda huduma ya mchanganyiko kwa mfumo huu wa mteja ambao unahitaji seti hii ya data ya mchanganyiko.

Baada ya muda, shirika zima litaanza kuelewa kuwa halihusu tena meza za hifadhidata, faili, vifurushi, vitendaji, taratibu, au rekodi. Sasa tunazungumza kuhusu usanifu unaozingatia huduma za kuvutia, zinazoweza kutumika tena na za atomiki zinazotolewa na programu za ESB.

Watu hawatafikiri tena kuwa programu na mifumo inatuma ujumbe kwa kila mmoja. Wataona ESB kama lango la wote kwa huduma za kuvutia ambazo mifumo yao wenyewe inaweza kutumia. Na hata hawataangalia nani hutoa nini, mifumo yao itashughulika na ESB tu.

Itachukua muda, uvumilivu na juhudi zilizoratibiwa, lakini inawezekana kabisa.

Lakini tahadhari...¶

Njia bora ya kuua wazo zima la SOA ni kupeleka ESB na kutarajia shida kujirekebisha. Ingawa ni wazo zuri, kupeleka tu ESB haitatosha, kwa bahati mbaya.

Kwa bora, kujaribu kuficha kitu chini ya rug, kama kwenye mchoro hapa chini, haitasababisha chochote:

Vijana wako wa IT watachukia mfumo na, ingawa wasimamizi watavumilia ESB kama suluhu mpya, baadaye itakuwa kicheko. “Je, hii ni risasi mpya ya fedha? Hahaha.”

Matokeo kama haya hayaepukiki ikiwa ESB si sehemu ya mpango mkubwa wa maendeleo.

Kwa hivyo, inageuka kuwa ESB ni ya benki tu na kadhalika?

Hapana kabisa. Hii ni suluhisho nzuri katika hali yoyote ambayo inahitaji kazi iliyoratibiwa ya vyanzo kadhaa vya data na mbinu kadhaa za kufikia ili kufikia matokeo ya kuvutia.

Kwa mfano, kazi ya kukusanya usomaji wa hivi punde kutoka kwa kihisi joto na kuyachapisha katika chaneli kadhaa, kama vile arifa za barua pepe na programu za iPhone, inafaa kwa jukwaa la ujumuishaji.

Kuangalia na kufuatilia mara kwa mara utendakazi wa matukio yote ya programu muhimu na, ikiwa sio zote zinazofanya kazi, kuendesha hati iliyosanidiwa na kutuma ujumbe wa maandishi kwa wasimamizi pia ni nzuri.

Chochote kinachohitaji kuunganishwa katika mazingira yaliyo wazi, yaliyofafanuliwa vyema kinaweza kuwa kinafaa kwa huduma ya ESB. Lakini, kama kawaida, kuamua ikiwa kitu kinafaa kwa ujumuishaji huja na uzoefu.

basi la huduma ya biashara

Bila shaka, timu ya Zato inaweza kusaidia.

Lakini nilisikia kuwa SOA ni XML, SOAP na huduma za wavuti¶

Ndiyo, hivyo ndivyo baadhi ya watu wangependa uamini.

Ikiwa watu au wachuuzi uliofanya nao kazi walituma faili ya CSV iliyosimbwa ya BASE64 katika ujumbe wa SAML2 uliolindwa wa SOAP, basi inaeleweka ni wapi ulipata maoni hayo.

XML, SOAP na huduma za wavuti zina hali zao za utumiaji, lakini kama kila kitu, zinaweza kutumiwa vibaya.

SOA inahusu usanifu wazi na unaoweza kudhibitiwa. Ukweli kwamba huduma inaweza au isitumie SABUNI haina umuhimu wowote. SOA kama mbinu ya usanifu bado itakuwa halali hata kama hakuna huduma ya SABUNI inatumika kabisa.

Ikiwa mbunifu hutengeneza jengo zuri, hawezi kuathiri rangi ya mambo ya ndani sana.

Kwa hivyo hapana, SOA sio XML, SOAP na huduma za wavuti. Wanaweza kutumika, lakini ni sehemu tu, sio msingi.

Unaweza kuwaelekeza wenzako waliopotea kwenye nakala hii ili waweze kujua SOA ni nini.

Zaidi zaidi¶

Sura hii inashughulikia mambo ya msingi tu, lakini bado inapaswa kutoa ufahamu wazi wa jinsi ESB na SOA zinapaswa kuonekana na kile kinachohitajika ili kufikia mafanikio.

Mada zingine ambazo hazijashughulikiwa hapa ni pamoja na (lakini sio tu):

• Jinsi ya kupata usaidizi wa usimamizi kwa kuanzisha ESB
• Jinsi ya kukusanya wasanifu wa SOA na timu za uchanganuzi
• Uwakilishi wa Canonical Data Model (CDM) katika shirika
• Viashiria Muhimu vya Utendaji (KPIs) - Kwa kuwa sasa una mbinu ya pamoja na iliyounganishwa ya kutoa huduma kati ya mifumo, unapaswa kuanza kuchunguza na kuchanganua kile ambacho kinawasilishwa kwako.
• Usimamizi wa Mchakato wa Biashara (BPM) - jinsi na wakati wa kuchagua jukwaa la BPM kwa usimamizi wa huduma (jibu sio haraka sana, kwanza jifunze jinsi ya kuunda huduma za kupendeza na muhimu)
• Nini cha kufanya na mifumo bila API? Kwa mfano, ikiwa ESB itapata ufikiaji wa moja kwa moja kwa hifadhidata zao (jibu ni inatofautiana, hakuna sheria ya dhahabu)

Kwa hivyo Zato ni nini?¶

Zato ni ESB na seva ya programu iliyoandikwa kwa kutumia Python na inaweza kutumika kutengeneza vifaa vya kati na mifumo ya nyuma. Ni programu huria yenye usaidizi wa kibiashara na jamii. Na Python ni lugha ya programu inayojulikana kwa urahisi na ufanisi wake.

Kutumia Python na Zato hukuruhusu kuongeza tija yako na kupoteza muda kidogo.

Zato iliandikwa pragmatists kwa pragmatists. Huu sio mfumo mwingine wa muuzaji aliyejengwa kwa haraka baada ya hype ya ESB/SOA.

Kwa kweli, Zato ilijengwa kwa kuzingatia uzoefu wa vitendo wa "kupambana na moto" unaosababishwa na mifumo hiyo. Kwa kweli, waandishi wa Zato walitumia muda mwingi kupigana na mazingira kama haya hivi kwamba hawakuweza kuvumilia moto wowote.

Hii ni ghushi ambayo Zato ilikuja ulimwenguni na kwa hivyo inaweza kutoa utendakazi na urahisi wa matumizi ambayo haipatikani katika suluhisho zingine zinazofanana.

Nitakuona ndani Hapa!

(Enterprise Service Bus) imeundwa ili kujenga mazingira ya habari iliyosambazwa ya biashara. Bidhaa ya programu huhakikisha mwingiliano wa programu zote zilizounganishwa katika kituo kimoja, kuchanganya vyanzo vilivyopo vya habari na kutoa ubadilishanaji wa data kati kati ya mifumo tofauti ya habari.

Enterprise Data Service Basi DATAREON ESB ni njia madhubuti ya kuhakikisha uthabiti na ukamilifu wa kubadilishana habari, kuongeza utendaji wa jumla wa mfumo wa habari na kupunguza gharama za wafanyikazi kwa usimamizi wake.

Basi la huduma ya biashara

Programu DATAREON ESB imejumuishwa rasmi katika rejista ya umoja wa programu za Kirusi kwa kompyuta za elektroniki na hifadhidata, ambazo zinaweza kununuliwa na taasisi za serikali na manispaa (https://reestr.minsvyaz.ru/).

Ili kuunganisha mifumo ya habari 2-3 katika makampuni madogo, DATAREON inatoa bidhaa ya programu iliyoundwa kwa misingi ya DATAREON ESB - DATAREON MQ.

Utendaji wa DATAREON ESB

Majukumu yametatuliwa kwa kutumia basi ya huduma ya data ya shirika

• Uhamisho wa data kati ya mifumo tofauti ya habari (pamoja na uelekezaji au uhakika-kwa-uhakika)
• Uundaji wa nafasi ya habari iliyounganishwa katika mazingira tofauti
• Kuunda mfumo uliosambazwa kulingana na muundo wa tukio katika chaguzi zifuatazo:
  • kujenga maombi na michakato ya biashara ya mwisho hadi mwisho kulingana na mfano wa tukio;
  • kuunda mfumo na maingiliano ya maombi ya biashara katika mifumo mbalimbali ya habari
• Risiti usanifu wa kudhibiti scalable kiwango cha biashara/umiliki
• Usambazaji mifumo ya kubadilishana data katika ngazi ya usafiri na katika ngazi ya mantiki ya biashara
• Kukabidhi kazi ya kuunda mtiririko wa habari idara za uchambuzi
• Kupunguza ugumu wa jumla wa muundo wa ujumuishaji na kupunguza mahitaji ya uwezo wa kituo
• Kuongezeka kwa utulivu wa jumla uhamishaji wa data ya safu ya usafirishaji
• Gharama za shughuli zilizopunguzwa wakati wa kubadilishana data kati ya idara tofauti
• Kupunguza gharama za jumla kwa ajili ya matengenezo na msaada wa mfumo wa habari.

Manufaa ya Basi la Huduma ya Data ya DATAREON ESB

• Ushirikiano wa haraka
• Kuegemea juu
• Uwezo wa kutumia tena rasilimali