Pamoja na nakala hii ningependa kufungua safu iliyowekwa kwa IBM WebSphere ESB(hapa inajulikana kama ESB) katika muktadha wa utengenezaji wa 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 tayari cha utumaji ujumbe na udhibiti wa kati wa mchakato huu, lakini pia seti kamili ya uwezo wa kutengeneza programu nyumbufu zinazoelekezwa kwa huduma haswa kwa ESB. Kama matokeo, uwezekano ufuatao unaweza kutambuliwa: Faida 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. Ufikiaji kwa kila mtu idara 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 ugumu wa mifumo biashara kubwa, basi inaweza kuitwa kwa hakika 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 sio ombi moja kwake linapaswa kupotea - unaweza kutumia huduma hiyo kushughulikia matukio ambayo hayakufanikiwa "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. Ya kwanza ni utumiaji tena wa usanidi (sawa na nambari na utumiaji wa moduli ambayo ni muhimu sana katika SOA), kwa sababu moduli tofauti na programu zinaweza kutumia vigezo sawa vya uunganisho wa hifadhidata, rasilimali, vigezo vya uthibitishaji, Vigezo vya Mazingira Nakadhalika.


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 matatizo yote ambayo yanahitaji kazi sambamba, bila udhibiti wa thread "mwongozo" (kwa mfano, unaweza kupiga simu za asynchronous kwa vipengele kadhaa na jibu la 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:

Wakati wa kuunganisha mifumo ya ushirika, kazi ya kusimamia data ya kumbukumbu hutokea. Ili kutatua tatizo hili, Usimamizi wa Data ya Mwalimu (MDM) hutumiwa mara nyingi. MDM ni hifadhi ambayo ina data ya kumbukumbu ya "rejeleo", kinachojulikana kama "rekodi za dhahabu". Saraka katika MDM zina data safi, kamili na thabiti.

MDM mara nyingi hutumiwa kama jukwaa la usimamizi wa saraka kuu. Data ya marejeleo imeingizwa na kuthibitishwa katika MDM, na kutoka hapo inaigwa kwa mifumo ya IT. Mbinu hii ina matatizo kadhaa

• Kuunda muundo wa data ya marejeleo ambayo inafaa mifumo yote si rahisi.
• Data ya marejeleo hutenganishwa na programu.
• Kuiga data kutoka kwa MDM mara nyingi kunahitaji marekebisho makubwa ya mfumo. Kwa mifumo ya nje ya sanduku, marekebisho hayo yanaweza kuwa ghali sana.

Mbinu nyingine ni kwamba kila mfumo wa biashara huhifadhi saraka ndani ya nchi na kupanga uwekaji data. Wakati wa kubadilishana ujumbe kati ya mifumo, basi ya ujumuishaji hufanya mabadiliko kutoka kwa muundo wa mfumo mmoja hadi umbizo la mwingine. Wakati huo huo, mabadiliko ya data ya kumbukumbu hutokea.

Mabadiliko kwenye basi ya ujumuishaji.

Tunatumia njia ya pili. Mwingiliano wote kati ya mifumo ya biashara hufanyika kupitia basi ya ujumuishaji. Basi (kwa upande wetu, Oracle Service Bus) hubadilisha ujumbe ambao mfumo wa Wasambazaji hutuma kuwa ujumbe ambao mfumo wa Watumiaji unaelewa. Mabadiliko haya yanajumuisha kuchora maadili ya saraka.

Data kuhusu jinsi saraka zinavyopangwa kati ya mifumo huhifadhiwa katika hifadhidata ya uhusiano, kwa upande wetu Oracle. Jedwali zitarekodi jinsi ya kupata thamani katika mfumo mwingine kutoka kwa thamani ya saraka katika mfumo mmoja. Hiyo ni, aina fulani ya muundo:

(mfumo_chanzo, thamani_chanzo, halali_kutoka, halali_kwenda, mfumo_lengwa, thamani_lengwa)

Data katika saraka hubadilika mara chache sana, lakini hutumiwa mara nyingi sana. Ili usipate hifadhidata kila wakati, saraka zimewekwa kwenye basi, na katika muundo ambao basi inaweza kutumia mara moja.

Kwa caching tunatumia. Hii ni bidhaa inayolipwa sana. Hata hivyo, katika kwa kesi hii Vipengele vyake vyote vya mega hazitumiwi, hivyo inaweza kubadilishwa kwa urahisi na ufumbuzi wa bure (kwa mfano, hazelcast). Unaweza kusoma zaidi juu ya mshikamano. Pia, leseni ya mshikamano imejumuishwa katika Oracle Suites mbalimbali.

Kutumia cache kuna faida dhahiri:

• data huhifadhiwa kwenye kumbukumbu
• data ni kuhifadhiwa katika fomu serialized
• data inaweza kuorodheshwa
• maingiliano na hifadhidata yanaweza kufanywa kwa usawa

Cache inasambazwa na maingiliano kati ya nodi hufanywa na Mshikamano yenyewe. Seva inapoongezwa au kuondolewa, nguzo husawazisha data kati ya nodi.

Ratiba ya Ramani ya Akiba Iliyosambazwa hutumiwa kwa data ya marejeleo. Wakati Oracle Service Bus inapoanza, kashe huundwa ndani ya JVM ambayo huhifadhi data kwenye kumbukumbu. Kwenye kila seva ya kimwili Kuna seva ya mshikamano ambayo huhifadhi saraka (katika kumbukumbu na kwenye diski) na inasawazishwa na hifadhidata.

Wakati wa mabadiliko, mtiririko wa kazi wa osb hufikia upatanisho kupitia wito wa Java. Inaweza pia kufikiwa kupitia simu ya Enterprise Java Bean.

Vipengele vya Basi la Huduma ya Biashara

Ushirikiano wa kisasa wa mifumo ya habari ni utekelezaji wa Usanifu wa Huduma-Oriented (SOA) kwa kutumia teknolojia za huduma za Mtandao; Kuna maelezo mengi bora ya faida na mbinu za kufanya hivi (tazama sehemu). Hivi majuzi, basi la huduma ya biashara limezingatiwa kuwa sehemu muhimu ya miundombinu ya SOA. Basi la Huduma ya Biashara(ESB) (tazama sehemu). Hata hivyo, ni muhimu kujua hasa ESB ni nini - bidhaa, teknolojia, kiwango, au kitu kingine chochote. Hasa, inawezekana kujenga ESB leo, na ikiwa ni hivyo, jinsi gani hasa?

Makala haya yanafafanua ESB kama seti ya utendakazi wa miundombinu inayotekelezwa kwa kutumia teknolojia ya vifaa vya kati vinavyotumia SOA. ESB inasaidia mwingiliano kwa kutumia huduma, ujumbe na matukio katika mazingira tofauti tofauti, yenye kiwango kinachofaa cha huduma na udhibiti. Katika makala hii tumekusanya na kuainisha zaidi kazi mbalimbali. Hata hivyo, si lazima kutumia vipengele hivi vyote katika hali zote za ESB.

Kifungu kinafafanua seti ya chini kabisa ya kazi zinazohakikisha kwamba mahitaji mengi ya ESB yanatimizwa kwa mujibu wa kanuni za SOA. Kwa kufafanua idadi ya chini kabisa ya vipengele, tunaweza kuelewa ni teknolojia ipi kati ya zinazopatikana inaweza kutumika kutekeleza ESB inayoauni SOA. Kwa kuelewa ni kazi gani za ziada zinaagizwa na mahitaji ya hali fulani, unaweza kuchagua teknolojia inayofaa zaidi ya utekelezaji kwa hali hii.

Makala yafuatayo yataelezea seti ya matukio ya ESB katika sehemu za kuanzia za SOA za kutekeleza ESB au SOA. Kwa upande mwingine, violezo vya suluhisho husaidia kuchagua teknolojia zinazofaa kwa utekelezaji.

Kadiri hali ambazo suluhu ya ESB inatumika inavyobadilika, utendakazi unaohitajika kwa ESB hubadilika ipasavyo. Kazi na vipengele vya bidhaa zinazotumia ESB kwa uwazi vitabadilika vivyo hivyo. Kwa hiyo, katika makala ya mwisho ya mfululizo huu, tutaangalia mfumo wa utekelezaji wa SOA na ESB ili kutoa mwongozo juu ya hatua ya kwanza ya kutumia vipengele na teknolojia za ESB na kuonyesha uwezekano wa utekelezaji wa taratibu.

Jukumu la ESB katika muundo wa SOA

Ingawa hatutazingatia ufafanuzi wa SOA kwa undani (tazama sehemu), bado itakuwa muhimu kukusanya hapa kanuni zote ambazo waandishi wengi wa ufafanuzi wa SOA wanakubaliana nazo:

• Kutumia miingiliano inayojitegemea kwa uwazi kufafanua huduma;
• Matumizi ya itifaki ya mawasiliano ambayo huongeza uwazi wa eneo na ushirikiano;
• Bainisha huduma zinazojumuisha vipengele vya biashara vinavyoweza kutumika tena.

Bila shaka, teknolojia tofauti zitakuwa na vikwazo tofauti katika uwekaji halisi wa violezo vinavyotumika - zingine zinaweza kufaa kwa usaidizi mkubwa sana wa usambazaji na ujumuishaji katika maeneo makubwa ya kijiografia, wakati zingine zinafaa zaidi kwa kutumwa katika vikundi vilivyojanibishwa na kusaidia suluhisho zinazopatikana sana. na scalability. Kuchora mahitaji ya kimwili ya usambazaji wa teknolojia zitakazotumika ni kipengele muhimu cha muundo wa ESB. Kwa kuongeza, ni muhimu sana kuhakikisha kwamba mfumo wa awali uliotumwa unaweza kupanuliwa kwa kuongezeka ili kuakisi mahitaji yanayoendelea, ushirikiano. mifumo ya ziada au kupanua upatikanaji wa kijiografia wa miundombinu.

Kielelezo 2. Usimamizi wa kati wa miundombinu ya ESB iliyosambazwa

Zaidi ya hayo, ESB inapaswa kuwekwa kuhusiana na vipengele vingine vya miundombinu ya SOA, hasa Saraka ya Huduma, Uchoraji wa Huduma za Biashara, na vipengele vya Lango la Biashara-kwa-Biashara (B2B). Kwa kuwa kanuni za SOA zilizoorodheshwa hapo juu hazihitaji vipengele hivi kuwepo, hebu tuzingatie vipengele vya hiari. Miundombinu ya SOA inaonyeshwa kuonyesha uhusiano wa vipengele hivi na ESB.

Kielelezo cha 3: Jukumu la ESB katika muundo wa SOA

Ili kuelekeza maombi ya huduma ya ESB, maalum saraka ya uelekezaji wa huduma. Walakini, SOA inaweza pia kuwa na tofauti orodha ya huduma za biashara, ambayo, kwa njia rahisi zaidi, inaweza kuwa saraka ya muda (inayotumiwa wakati wa maendeleo ya mradi) ambayo hutumiwa kuwezesha utumiaji wa huduma na watengenezaji wa shirika. Katika mwonekano wa huduma za Wavuti, jukumu la saraka ya huduma ya biashara na saraka ya uelekezaji wa huduma hupewa saraka ya UDDI, na hivyo kuhakikisha ugunduzi wa nguvu na uombaji wa huduma. Saraka kama hiyo inaweza kuzingatiwa kuwa sehemu ya ESB, lakini hadi suluhisho kama hizo zitakapoenea, ni bora kuweka saraka ya huduma ya biashara tofauti na ESB.

Kazi ya sehemu ya Huduma ya Biashara ya Choreographer ni mpangilio michakato ya biashara kutoka kadhaa huduma za biashara; kwa hivyo, kipengele hiki huita huduma kupitia ESB na kisha kutoa michakato ya biashara kwa wateja kama huduma zingine, pia kupitia ESB. Hata hivyo, jukumu la Kipengele cha Mtaalamu wa Huduma ya Biashara, teknolojia ya mchakato wa utengenezaji, katika kuratibu uendeshaji wa michakato na huduma za biashara hubainisha kipengele hiki kuwa si sehemu ya ESB, teknolojia ya miundombinu.

Hatimaye, kazi ya sehemu ya B2B Gateway ni kufanya huduma za kila moja ya mashirika mawili au zaidi kupatikana kwa mashirika mengine yote kwa njia iliyodhibitiwa na salama. Ni muhimu kufikiria vipengele kama vilivyounganishwa na ESB, lakini sio sehemu yake. Ingawa kuna milango teknolojia, kutoa utendakazi unaohitajika kutekeleza B2B Gateway na vipengele vya ESB, yenyewe uteuzi Sehemu ya B2B Gateway inaitenganisha na ESB. Kwa hakika, kipengele hiki kinaweza kuhitaji zana za ziada ili kutekeleza majukumu yake, kama vile zana za usimamizi wa ubia ambazo si sehemu ya ESB na haziungwi mkono na teknolojia za ESB.

Mfano wa Utendaji wa ESB

Hufupisha na kuainisha baadhi ya kazi za ESB zilizofafanuliwa katika fasihi iliyopo (ona sehemu). Baadhi ya vipengele hivi ni rahisi, huku vingine, kama vile uhuru na akili, vinawakilisha hatua muhimu kuelekea mazingira ya uendeshaji ya On Demand. Ni muhimu kuelewa kwamba kwa visa vingi vya utumiaji vya ESB vilivyopo, ni baadhi tu ya vipengele hivi kutoka kwa baadhi ya kategoria ni muhimu. KUHUSU kiwango cha chini Tutajadili seti ya kazi zinazohitajika kutekeleza ESB katika sehemu hiyo Kipengele cha chini cha ESB Kimewekwa kwa SOA.

Jedwali 1. Kazi za ESB zilizoelezwa katika fasihi maalumu

Uhusiano	Mwingiliano wa huduma
Uelekezaji; Akihutubia; Teknolojia za mawasiliano, itifaki na viwango (kama vile IBM® WebSphere® MQ, HTTP na HTTPS) Chapisha/jiandikishe; Jibu/ombi; Moto-na-kusahau matukio; Ujumbe unaosawazishwa na usio na usawa.	Ufafanuzi wa kiolesura cha huduma (kwa mfano, lugha ya WSDL (Lugha ya Maelezo ya Huduma za Wavuti); Msaada kwa uwezo wa kuchukua nafasi ya utekelezaji wa huduma; Mtindo wa shirika la huduma ya ujumbe unaohitajika kwa mawasiliano na ujumuishaji (kwa mfano, SOAP au muundo wa ujumuishaji wa programu ya biashara (EAI) wa vifaa vya kati); Saraka ya huduma na ugunduzi wa huduma.
Kuunganisha	Ubora wa huduma
Hifadhidata; Mkusanyiko wa huduma; Adapta za mifumo na programu zilizopo; Kutoa muunganisho kwa vifaa vya kati vya EAI; Maonyesho ya huduma; Uongofu wa itifaki; Mazingira ya seva ya programu (kama vile J2EE na .NET); Kiolesura cha lugha ya programu ya kupiga huduma (kwa mfano, Java na C/C++/C#).	Shughuli (Shughuli zisizogawanyika, Fidia, shughuli za WS); Vielelezo mbalimbali vya uwasilishaji vilivyohakikishwa (km WS-ReliableMessaging au usaidizi wa vifaa vya kati vya EAI).
Usalama	Kiwango cha huduma
Uthibitisho; Uidhinishaji; Kutowezekana kwa kuacha uandishi; Usiri; Viwango vya usalama (kwa mfano, Kerberos na WS-Security).	Utendaji; Bandwidth; Upatikanaji; Hatua nyingine zinazoendelea ambazo zinaweza kuwa msingi wa mikataba au makubaliano.
Uchakataji wa ujumbe	Udhibiti na uhuru
Mantiki yenye msimbo; Mantiki ya msingi wa yaliyomo; Mabadiliko ya ujumbe na data; ukaguzi wa uhalali; Mwanzilishi; Onyesho sawa la vitu; Uboreshaji wa data.	Uanzishaji na usajili wa huduma; Kuweka magogo, vipimo, ufuatiliaji; Ugunduzi; Kuunganishwa na zana za usimamizi na usimamizi wa mfumo; Kujiangalia na kujisimamia.
Kuiga	Vipengele vya Miundombinu vya Akili
Mfano wa kitu; Mifano ya jumla ya vitu vya biashara; maktaba za muundo wa data; Mifano ya wazi au iliyofungwa kwa ushirikiano wa B2B; Vyombo vya maendeleo na usambazaji.	Sheria za biashara; Tabia inayoendeshwa na sera, hasa kwa kiwango cha huduma, usalama, na vipengele vya ubora wa huduma (km, Sera ya WS); Utambuzi wa muundo.

Nyingi za kazi hizi zinaweza kutekelezwa kwa kutumia teknolojia zinazofaa au kutumia viwango vya wazi. Lakini teknolojia zinazostahiki kutumika katika utekelezaji wa ESB zinaweza kutofautiana sana kulingana na utendakazi, ukubwa, na upatikanaji, na vile vile vipengele vya ESB na viwango vilivyo wazi vinavyotumia. Kwa sababu hizi na kutokana na ukweli kwamba baadhi ya viwango vya maana zimetengenezwa hivi karibuni au bado ziko chini ya maendeleo, nyingi muhimu maamuzi muhimu Utekelezaji wa ESB kwa sasa unahusisha ubadilishanaji kati ya teknolojia zinazotumika kukomaa, zilizoanzishwa na viwango vilivyo wazi kidogo.

Sitaingia kwa undani juu ya kila moja ya kategoria hizi katika safu hii ya nakala. Badala yake, tutazingatia yale ambayo ni muhimu kwa maamuzi kuhusu uchaguzi wa mbinu ya kutekeleza au kutekeleza ESB. Hasa, katika sehemu inayofuata tutaangalia seti ya chini kabisa ya vipengele vinavyohitajika kwa utekelezaji wa ESB ili kusaidia SOA.

Kipengele cha chini cha ESB Kimewekwa kwa SOA

Ikiwa kwa hali nyingi za SOA ni sehemu ndogo tu ya vipengele vilivyoorodheshwa hapo awali vinavyofaa, tunaweza kuuliza swali lifuatalo: ni vipengele vipi vilivyojumuishwa? kiwango cha chini seti ya kazi zinazohitajika kutekeleza ESB? Kujibu swali hili, tutaangalia mambo ya kawaida ya ufafanuzi wa ESB, ambayo kuna kutokubaliana kidogo:

• ESB ni sehemu ya kimantiki ya usanifu ambayo hutoa miundombinu ya ujumuishaji inayolingana na kanuni za SOA;
• Kanuni za SOA zinahitaji matumizi ya violesura vinavyotegemea utekelezaji, itifaki za mawasiliano zinazoboresha uwazi wa mpangilio na ushirikiano, na ufafanuzi wa huduma ambao ni mzuri kiasi na unaojumuisha utendakazi unaoweza kutumika tena;
• ESB inaweza kutekelezwa kama miundombinu tofauti tofauti iliyosambazwa;
• ESB hutoa zana za kudhibiti miundombinu ya huduma yako na kukuwezesha kufanya kazi katika mazingira ya leo yaliyosambazwa na tofauti.

Ifuatayo ni seti ya chini kabisa ya vitendaji vya ESB vilivyochaguliwa kwa kuzingatia kanuni hizi.

Jedwali 2. Seti ya chini ya kazi za ESB

Uhusiano	Kuunganisha
Kuelekeza na kushughulikia huduma ili kuhakikisha uwazi wa uwekaji; Kazi ya utawala ya kusimamia kushughulikia na kutaja huduma; Angalau aina moja ya dhana ya ujumbe (k.m., ombi/jibu, chapisha/jisajili, n.k.); Usaidizi wa angalau itifaki moja ya usafiri ambayo inapatikana au inaweza kupatikana kwa umma.	Inaauni miunganisho mingi na watoa huduma, kama vile viunganishi vya Java 2, huduma za Wavuti, utumaji ujumbe usiolingana, adapta, n.k.
Mwingiliano wa huduma
Mfano wazi na wa kujitegemea wa utekelezaji wa shirika la ujumbe na kiolesura, ambacho kinapaswa kutenganisha nambari ya maombi kutoka kwa hali maalum za uelekezaji wa huduma na. itifaki za usafiri, pamoja na kuhakikisha uwezekano wa kuchukua nafasi ya utekelezaji wa huduma

Tafadhali kumbuka kuwa seti ya chini kabisa ya vitendakazi hauhitaji matumizi ya teknolojia yoyote maalum mfano EAI middleware, Huduma za Wavuti, J2EE au XML. Kuna uwezekano kwamba teknolojia hizo zitatumika kwa sababu zinakidhi mahitaji, lakini hii sio lazima. Kinyume chake, seti ya chini ya kazi ni karibu, ikiwa sio kabisa, iliyotolewa rahisi kutumia SABUNI/HTTP na WSDL.

• Anwani ya URL na miundombinu iliyopo HTTP na DNS hutoa miundombinu ya "basi" ambayo hutoa uelekezaji wa huduma na uwazi wa uwekaji;
• SOAP/HTTP inasaidia dhana ya utumaji ujumbe ombi-jibu;
• Usafiri Itifaki ya HTTP inapatikana kwa wingi;
• SOAP na WSDL hutoa mfano wazi, unaotegemea utekelezaji wa kupanga kiolesura na utumaji ujumbe wa huduma.

Walakini, kutumia SOAP/HTTP na WSDL kwa njia rahisi zaidi hutoa tu muunganisho wa uhakika na haitoi yafuatayo. kazi muhimu inahitajika kwa ESB:

• Haipo kazi ya utawala ili kudhibiti kushughulikia na kutaja huduma Majina ya huduma yanadhibitiwa kibinafsi na kila adapta, kwa hivyo udhibiti wa uelekezaji wa huduma husambazwa kati ya anwani zinazoitwa na wateja wa huduma, miundombinu ya HTTP, na majina ya huduma yaliyotolewa kwa adapta;
• Ingawa mbinu hii inategemea maelezo ya utekelezaji, haichangii katika kutoa utekelezaji wa huduma mbadala; Msimbo wa mwombaji huduma (unaoweza kuzalishwa na zana za ukuzaji) mara nyingi utahusishwa moja kwa moja na utekelezaji mahususi wa mtoa huduma kupitia itifaki maalum kwenye anwani mahususi. Kubadilisha utekelezaji wa huduma na utekelezaji mwingine itahitaji mabadiliko ya msimbo wa maombi na uwekaji upya.

Bila shaka, matukio mengi au hata mengi yanahitaji vipengele vya ziada ambavyo vitakuwa vya kawaida zaidi kwa muda. Hasa, aina zifuatazo mahitaji yanaweza kusababisha matumizi ya teknolojia ya kisasa zaidi, sasa au katika siku zijazo:

• Kazi za kuhakikisha ubora wa huduma na kiwango cha huduma;
• Dhana za SOA ni zaidi ngazi ya juu- choreography ya huduma, katalogi, mabadiliko, nk;
• Mahitaji ya mazingira ya uendeshaji kama vile uhuru na vipengele vya usimamizi, pamoja na akili ya miundombinu;
• Uendeshaji tofauti kabisa kwenye mitandao mingi, itifaki nyingi na vikoa vingi na mifano tofauti mali.

Masuala ya usalama yanayohusiana na ESB

Makala haya hayakukusudiwa kushughulikia mahitaji ya usalama yenyewe, lakini yanaweza kuwa muhimu wakati wa kuchagua teknolojia ya ESB. Kwa mfano, ikiwa hakuna haja ya uthibitishaji na idhini ya maombi kwa seva, basi uchaguzi wa teknolojia unaweza kuwa mkubwa sana. Ikiwa kiwango fulani cha usalama kinahitajika, kama inavyowezekana zaidi, basi ni muhimu kutathmini ni mtindo gani wa usalama utakubalika. Kwa mfano:

1. Je, kiwango cha usalama cha miundombinu ya mawasiliano kitakubalika unapotumia uthibitishaji wa pande zote wa Tabaka la Soketi Salama la EAI kati ya seva za vifaa vya kati vya EAI au unapotumia HTTPS?
2. Je, usalama wa mtu binafsi, wa hatua kwa hatua kati ya mifumo inayoshiriki utatosha, au mfano wa usalama wa mwisho hadi mwisho ni muhimu? Kwa mfano, kuna haja ya kusambaza taarifa za utambulisho wa mteja kupitia mifumo ya kati kama vile madalali hadi watoa huduma au utekelezaji wa huduma?
3. Je, usalama utakubalika kiwango cha maombi, kwa mfano, nambari ya mteja inaweza kutekeleza uthibitishaji wa msingi HTTP kwa mtumiaji na nenosiri, au itaweza kupitisha maelezo haya kwa huduma kama data ya programu?
4. Je, utaratibu wa usalama unahitaji kutii viwango vya usalama kama vile Kerberos au WS-Security?

Ingawa mbinu hizi zote za usalama zinawezekana, tunapendekeza kutumia vipengele vya usalama vinavyotii viwango (kama vile WS-Security) vinavyoauniwa na miundombinu na vifaa vya kati. Hata hivyo, viwango hivi ni vipya, na usaidizi kwao katika bidhaa za programu bado uko katika awamu ya maendeleo, hasa katika kesi zinazohusiana na kuhakikisha ushirikiano. Kwa hivyo, moja ya vipaumbele vya usanifu wa ESB inapaswa kuwa kuanzisha mahitaji ya usalama mapema katika awamu za maendeleo ili waweze kuzingatiwa wakati wa kuchagua teknolojia ya utekelezaji.

Hitimisho

Nakala hii ilizungumza juu ya kanuni za jumla za SOA na unganisho lao na teknolojia ya huduma za Wavuti. Kulingana na kanuni hizi, mwandishi anasema kuwa sehemu ya miundombinu ambayo hutoa kazi ya uelekezaji lazima ihakikishe mwingiliano wa huduma na kila mmoja, na pia msaada wa kuchukua nafasi ya utekelezaji mmoja wa huduma na utekelezaji mwingine. Kazi hizi, kati ya nyingine nyingi, zinatekelezwa kupitia ESB.

ESB hutoa miundombinu iliyosambazwa na utendaji wa usimamizi wa kati, ambayo inahitaji saraka ya uelekezaji wa huduma na, kwa kuongeza, ikiwezekana saraka ya huduma ya biashara. Kipengele cha Mchoraji wa Huduma ya Biashara huita huduma kutoka kwa ESB na kisha kufichua michakato kama huduma mpya kupitia ESB.

Miongoni mwa huduma nyingi zinazotolewa na ESB ni zifuatazo:

• Mawasiliano;
• mwingiliano wa huduma;
• Ushirikiano;
• Kuhakikisha ubora wa huduma;
• Usalama;
• Kuhakikisha kiwango cha huduma;
• usindikaji wa ujumbe;
• Usimamizi wa huduma na uhuru;
• Modeling;
• Kazi za miundombinu zenye akili.

Katika makala inayofuata katika mfululizo, tutaangalia matukio ya kawaida, mifumo sahihi ya ufumbuzi wa matukio, na kuzungumza juu ya matatizo ya kawaida yanayohusiana na matukio haya.

Shukrani

Makala haya yasingechapishwa bila mwandishi kujadili mawazo yake na watu wafuatao: Beth Hutchison, Rachel Reinitz, Olaf Zimmerman, Helen Wylie, Kyle Brown ( Kyle Brown, Mark Colan, Jonathan Adams, Paul Fremantle, Keith Jones, Paul Verschueren , Daniel Sturman, Scott Cosby Cosby), Dave Clarke, Ben Mann, Louisa Gillies, Eric Herness, Bill Hassell, Guru Vasudeva, Kareem Yusuf ), Ken Wilson, Mark Endrei, Norbert Bieberstein, Chris Nott, Alan Hopkins na Yaroslav Dunchych.

Ujumuishaji wa maombi ni suala ambalo mapema au baadaye litakabili idara ya TEHAMA ya shirika lolote ambalo lina zaidi ya moja ya programu hizi. Mbali na hilo orodha kamili kazi zinazolingana na dhana ya "muunganisho":

• hitaji la kudumisha saraka za jumla (kwa mfano, saraka za wateja au wafanyikazi);
• kuzindua shughuli katika mfumo mmoja wa habari wakati matukio yanatokea kwa mwingine;
• mchakato wa biashara (mlolongo uliopangwa wa vitendo vinavyofanywa na watu na mifumo ya habari) inayotokea katika maombi kadhaa;
• mwingiliano wa habari na washirika wa biashara (kwa mfano, ombi otomatiki bei ya vifaa kutoka kwa muuzaji);
• umoja wa kubadilishana habari na michakato ya biashara katika matawi ya kampuni.

Ikiwa aina hii ya hatua hutokea mara chache katika biashara (kwa mfano, mara moja kwa siku), basi vitendo hivi vinaweza kupangwa kwa njia ya muda - kwa mfano, kwa kupakia data kutoka kwa programu moja hadi Muundo wa Excel na kuzipakia kwenye programu nyingine au hata kutumia ingizo lililorudiwa la habari katika mifumo miwili mara moja. Walakini, ikiwa ni lazima mwingiliano wa habari maombi hutokea mara nyingi kwa siku, swali linatokea kuhusu matumizi yasiyofaa ya rasilimali za binadamu na, kwa sababu hiyo, kuna haja ya automatiska utaratibu huu.

Ujumuishaji wa hatua kwa hatua

Kazi ya kuunganisha kwa uhakika ni rahisi. Inahitajika kuelewa jinsi kila moja ya mifumo miwili inayoingiliana iko tayari kusambaza na kupokea data, kuunda masuluhisho ya kiufundi ya kufikia miingiliano hii, na pia kutekeleza utaratibu wa kubadilisha data kutoka kwa umbizo la mfumo wa chanzo hadi umbizo la mfumo lengwa. Katika hali nzuri, mifumo ya habari hutoa interface maalum ya programu (API) kwa ajili ya kuunganishwa, na katika hali mbaya zaidi, habari lazima isomwe na kuandikwa moja kwa moja kwenye hifadhidata ya maombi. Matokeo yake, ufumbuzi wa ushirikiano wa ndani hutokea - moduli tofauti ya programu ya maendeleo yetu wenyewe na mahitaji yote yanayofuata kwa ajili ya matengenezo yake na kudumisha umuhimu wake.

Ujumuishaji wa hatua kwa hatua

Hii haina kiasi tatizo kubwa mradi tu kuna miunganisho michache ya kumweka-kwa-hatua - moja au mbili. Hata hivyo, mazoezi yanaonyesha kwamba idadi ya ushirikiano wa hatua kwa hatua huelekea kuongezeka, na ubora wa usimamizi wa ushirikiano huu, kinyume chake, hupungua kwa kasi. Kuna sababu nyingi za hili: idadi ya moduli za ushirikiano zinaongezeka, watengenezaji ambao walifanya moduli moja au nyingine wanaondoka kwenye shirika, muundo wa data katika mifumo iliyounganishwa inabadilika, nk. Matokeo ya kusikitisha ya maendeleo ya mageuzi ya miunganisho ya uhakika ni "mincemeat" ngumu zaidi ya mwingiliano wa ushirikiano kati ya maombi ya biashara, mtazamo kuelekea ni nani wa wafanyakazi wa idara ya IT unaweza kuonyeshwa kwa urahisi kwa maneno machache: "Mradi tu inafanya kazi, ni bora usiiguse." Hata hivyo, hali hii haifai ama idara ya IT yenyewe au wateja wa biashara.

Integration stuffing

Basi la huduma moja

Baada ya kupitia vizazi kadhaa vya mbinu tofauti za ujumuishaji wa programu, tasnia ya programu ya kimataifa imekuja kwenye dhana ya Basi moja la Huduma ya Biashara (ESB). Kutoka kwa mtazamo wa usanifu, ESB ni suluhisho la programu, kuhakikisha mwingiliano wa programu zote zilizounganishwa kupitia nukta moja, kwa usawa, kuwapa wasanidi programu na wasimamizi njia zilizounganishwa na kuu za kuendeleza, kupima na kufuatilia maendeleo ya matukio yote ya ujumuishaji.

Sehemu kuu zinazounda basi ya kisasa ya huduma ni:

• wakala wa ujumbe ni uti wa mgongo wa utendaji wa juu wa kubadilishana ujumbe katika umbizo la umoja kati ya programu kwa wakati halisi;
• adapta - adapta za kiteknolojia na adapta kwa mifumo ya biashara hutoa mwingiliano na programu katika muundo unaokubalika kwao, ikiwasilisha habari kutoka kwa jumbe hizi katika umbizo la umoja linalotambuliwa na wakala - kadiri adapta tofauti hutoa jukwaa fulani la ujumuishaji, ndivyo nafasi inavyoongezeka. kwamba utekelezaji wake katika shirika lako hautahitaji kazi ya ziada ili kuunda adapta maalum kwa mifumo yako;
• mazingira kwa ajili ya kuendeleza matukio ya ushirikiano - jinsi maendeleo ya matukio ya ushirikiano yanavyokuwa rahisi na ya haraka, uwekezaji mdogo katika maendeleo haya, na kwa hiyo kasi ya kurudi kwenye uwekezaji. Basi ya kisasa ya ushirikiano hutoa msanidi zana za kuona kwa ajili ya kujenga matukio ya ushirikiano, ambayo katika hali nyingi hufanya iwezekanavyo kufanya bila coding ya kiwango cha chini;
• Vyombo vya SOA - kufuata kanuni za usanifu unaoelekezwa kwa huduma ni kiwango kisicho na masharti cha suluhisho zote za ujumuishaji wa aina ya "basi ya huduma moja" (kama ilivyo wazi kutoka kwa jina lake). Mifumo ya habari inazingatiwa hapa kama watoa huduma na watumiaji wa huduma; huduma zote zilizochapishwa kwenye basi huwekwa ndani rejista moja na uwezo wa kutumia tena na kudhibiti sera zinazohusiana na huduma;
• vyombo mbalimbali udhibiti na usimamizi (ukaguzi, ukataji miti, ufuatiliaji wa kati, ufuatiliaji wa kufuata mikataba ya kiwango cha huduma, n.k.).

Faida za kutumia basi moja ya huduma ni pamoja na:

• kuongeza - uwezo wa kujenga ufumbuzi wa ukubwa wowote na mzigo;
• kubadilika - uwezo wa kutekeleza na kubadilisha matukio ya ushirikiano bila ushiriki mkubwa wa watengenezaji;
• usalama - zana za uthibitishaji na uidhinishaji zilizojengwa hutoa udhibiti wa ufikiaji wa huduma kwa kiwango cha basi yenyewe, kuwaondoa watengenezaji wa matukio ya ujumuishaji kutoka kwa kazi ya kutekeleza taratibu hizi;
• matumizi ya viwango vya wazi - inakuwezesha kupunguza ushiriki wa wataalam wa gharama kubwa katika teknolojia za wamiliki;
• ujumuishaji wa zana za udhibiti na usimamizi - hukuruhusu kuzuia "kutia ukungu" hatua ya uwajibikaji kwa hali za ujumuishaji, hakikisha ufuatiliaji wa kiutendaji na onyo la mapema ikiwa utashindwa.

Sharti lingine muhimu kwa utendakazi wa mazingira ya ESB ni uwezo wa kutekeleza ujumuishaji na mashirika ya nje- washirika wa biashara, wauzaji, wateja wa kampuni, matawi ya mbali. Vipengele vya ujumuishaji kama huo ni ubora usiotabirika wa chaneli, ukosefu wa dhamana ya uwasilishaji wa habari na utayari duni wa kuunganishwa kama vile - kama sheria, shirika la washirika hutoa anuwai ndogo ya muundo wa kubadilishana data. Katika hali hii, basi ya ujumuishaji lazima iwe na zana ya kuunda mwingiliano wa B2B ambayo inaruhusu kubadilishana habari kulingana na wazi, pamoja na viwango vya tasnia, kuhakikisha uwasilishaji wa uhakika, ina njia ya kusanidi ubadilishanaji wa habari katika muktadha wa mshirika maalum wa biashara na, bila shaka, fanya kazi kwa ukamilifu kulingana na kanuni za jukwaa la ushirikiano yenyewe, kutenganisha msanidi wa matukio ya ushirikiano kutoka kwa maelezo ya kiufundi ya mwingiliano na mpenzi.

Basi la Huduma ya Biashara

Usimamizi wa mchakato wa biashara

Sehemu kubwa ya hali za ujumuishaji inamaanisha kuwa ubadilishanaji wa habari hauhusishi tu programu zinazofanya kama vyanzo au wapokeaji wa habari, lakini pia watu - wafanyikazi wa shirika wanaofanya kazi mbali mbali au kufanya maamuzi. Katika kesi hii, tunaweza kuzungumza juu ya kwenda zaidi ya ujumuishaji "safi" na kuibuka kwa chombo kipya katika mwelekeo wa umakini wetu - michakato ya biashara, na katika mahitaji ya jukwaa la ujumuishaji - utendaji mpya wa usimamizi wa mchakato wa biashara (Usimamizi wa Mchakato wa Biashara. , BPM). Ikiwa kuna mahitaji ya BPM, ni lazima jukwaa la ujumuishaji limpe msanidi programu:

• chombo cha muundo wa kuona wa michakato ya biashara - ni bora kwamba zana hizi zinaweza kutumiwa na watu walio mbali na IT, kwa mfano, wachambuzi wa biashara au wataalam wa mbinu. Kwa kuongeza, uwezo wa kuhamisha mifano ya mchakato wa biashara kutoka kwa zana maalum za uundaji hadi mazingira ya maendeleo ni muhimu sana. Chombo sawa kinapaswa kufanya iwezekanavyo kuunda fomu za kazi kwa washiriki wa mchakato, kulinda watengenezaji iwezekanavyo kutoka kwa programu;
• mazingira ya utekelezaji wa mchakato wa biashara - injini maalum ambayo hutoa usindikaji wa sheria za biashara, uhamisho wa kazi kati ya watumiaji na mifumo ya habari kwa mujibu wa mifano ya mchakato wa biashara iliyoendelea, pamoja na usindikaji. hali za kipekee(kwa mfano, mtendaji huzidi muda uliowekwa kwa ajili ya kukamilisha kazi);
• lango la washiriki wa mchakato wa biashara - lango maalum ambalo huruhusu watumiaji kuzindua michakato, kushiriki kwao na kufuatilia maendeleo. michakato inayoendesha na kutekeleza hatua za kiutawala kwa mujibu wa haki zilizowekwa kwa ajili yao;
• zana za ufuatiliaji na udhibiti. Uwezo wa kuchambua kwa haraka na upya mtiririko wa michakato ya biashara ni sehemu muhimu ya jukwaa lolote la BPM.

Wauzaji wengi wa programu sasa wanahamia kuchanganya mfumo wa BPM na basi ya ujumuishaji kwenye jukwaa moja la vifaa vya kati, kuondoa utengano mkali kati ya mifumo ya BPM na zana za ujumuishaji wa programu ambazo zimekuwepo kwa miaka kadhaa. Mbinu hii ni ya kimaendeleo sana. Wachuuzi wengine huenda mbali zaidi na kuongeza zana za uundaji wa mchakato wa biashara kwenye jukwaa. Software AG inaanzisha hili kwa kutumia suluhisho linalochanganya zana maarufu ya uundaji wa Mfumo wa ARIS na ujumuishaji wa webMethods/mazingira ya BPM.

Matumizi kamili ya jukwaa la ujumuishaji

Inatoa kwenye soko

Washa wakati huu Kuna vikundi vitatu vya matoleo ya programu kwa ajili ya kujenga ESBs. Vikundi hivi hutofautiana katika bei na utendaji unaotolewa.

Kundi la kwanza ni mapendekezo kutoka kwa makampuni ambayo bidhaa zao ni viongozi katika utafiti na mashirika ya uchambuzi katika makundi yote yaliyoonyeshwa katika makala (ESB, SOA Governance, BPM, B2B). Kundi hili ni pamoja na:

• IBM na laini yake ya bidhaa ya WebSphere;
• Programu AG yenye jukwaa la ujumuishaji la webMethods;
• Oracle na mfululizo mzima wa mapendekezo;
• Tibco na laini ya Ujumuishaji wa Biashara.

Kimsingi, wale ambao hawapendi maelewano wanaweza kuchagua yoyote ya watengenezaji hawa - kampuni zote zilizoorodheshwa hutoa mistari kamili ya bidhaa (hata hivyo, katika kesi ya Oracle sio wazi kila wakati ni bidhaa gani tunazungumza, kwani baada ya kununua nambari. Makampuni ya Oracle hutoa bidhaa kadhaa mara moja, sio kila wakati zimeunganishwa vya kutosha na kila mmoja). Tibco inasimama kando kidogo, kwa kuwa saizi ya kampuni hii ni ndogo sana kuliko saizi ya wanachama wengine wa hii nne, ambayo inaweza kuongeza mashaka juu ya uthabiti wake. Programu AG - bado haijajulikana sana Soko la Urusi mtengenezaji, lakini jukwaa la webMethods, ambalo ni toleo la msingi la kampuni leo, lina uwezo mkubwa. IBM na bidhaa zake tayari zinajulikana na hutumiwa na makampuni mengi ya biashara, lakini baadhi yao wana malalamiko kuhusu gharama ya kutekeleza na kudumisha mfumo.

Kundi la pili la mapendekezo ni makampuni ambayo yanazingatia hasa utendaji wa "safi" wa ESB na wamepata mafanikio hapa. Kundi hili linajumuisha: Sun (Glassfish), Maendeleo (Sonic) na Fujitsu.

Ofa kutoka kwa kampuni hizi ni nzuri ikiwa huna nia ya kupanua wigo wa jukwaa lako kuelekea BPM na/au B2B. Vinginevyo, unaweza kuhatarisha kuachwa na utendakazi ambao haujatengenezwa vya kutosha na kuongeza gharama zako za kuiboresha ili kukidhi mahitaji yako.

Kundi la tatu ndilo lililo wengi zaidi na linajumuisha mapendekezo yote ambayo hayakujumuishwa katika makundi mawili yaliyotangulia. Kuorodhesha mapendekezo yote kwenye mada ya ESB katika nakala hii haina maana; unaweza kupata orodha kama hiyo kwenye injini yoyote ya utaftaji. Ikiwa bajeti yako ya ujumuishaji ni ndogo, na una mwelekeo wa kujaribu, unaweza kujaribu bahati yako na yoyote kati yao. Hata hivyo, hatari zinazohusiana na utendakazi usiotosheleza na matatizo yanayoweza kutegemewa msaada wa kiufundi na matarajio ya maendeleo ya bidhaa, unadhani.

Hitimisho

Kwa kumalizia, ningependa kuwapa wasomaji machache vidokezo rahisi kwa uchaguzi wa basi ya ujumuishaji:

• fikiria juu ya kujenga suluhisho la ujumuishaji bila kungoja maswala ya mwingiliano wa programu kukusukuma ukutani. Kadiri kifusi kinavyokuwa kikubwa, ndivyo inavyokuwa vigumu zaidi kuisafisha;
• Chagua jukwaa lako kwa uangalifu. Tafuta muuzaji ambaye anakidhi wewe katika mambo yote, kwa kuwa sasa kuna mengi ya kuchagua. Unapaswa kupendezwa na vigezo vyote vya kiteknolojia vya jukwaa na vipengele vya mbinu za utekelezaji;
• fikiria kuhusu wakati ujao. Mahitaji ya kazi ambayo unatambua sasa yanaweza kubadilika sana kwa mwaka, na ikiwa jukwaa halijakidhi, basi itabidi "uhamie" hadi nyingine. Na hoja moja, kama unavyojua, ni sawa na moto mbili.

Katika mageuzi ya haraka ya teknolojia ya kompyuta, uwezekano mpya wa mawazo ya zamani wakati mwingine hufunuliwa kabisa bila kutarajia. Kwa mfano, kama vile, inaweza kuonekana muda mrefu uliopita kumbukumbu iliyosahaulika kwenye cores ya ferrite. Licha ya mapungufu yake yote, ubora wake mzuri ulikuwa uwezo wa kukumbuka na kuhifadhi data kwa muda usiojulikana bila recharging - tofauti na modules za kisasa za semiconductor RAM. Na sasa, halisi mbele ya macho yetu, inafufuliwa kwa namna ya kuahidi teknolojia ya MRAM, ambayo pia hutumia kitanzi cha magnetic hysteresis cha nafasi mbili. Kwa hivyo, itadumisha hali yake bila lishe. Kwa uamsho wa kumbukumbu ya sumaku, utaratibu kama huo unaojulikana wa kuwasha kompyuta utakuwa jambo la zamani.

Kitu kama hicho hufanyika kwa njia kuu za kubadilishana data zilizojengwa kwa kanuni ya " basi ya kawaida" Sasa ni ngumu kufahamu asili ya mapinduzi ya wazo la basi ya kawaida, lakini wakati mmoja ilikuwa mapinduzi ya kweli. Basi la kawaida la Unibus, lililopendekezwa miongo mitatu iliyopita na wahandisi katika Shirika la Vifaa vya Dijiti kama msingi wa usanifu wa kompyuta ndogo ya PDP-11, liligeuka kuwa njia bora sana (na muhimu zaidi, nafuu) ya kuunganisha aina tofauti za vifaa. Baadaye, kompyuta nyingi zilijengwa kwa kanuni ya basi, pamoja na Kompyuta zote za kisasa. Kweli, soko lilianza kuunda kutoka kwa basi ya kawaida vifaa vya pembeni. Walakini, baada ya muda, mabasi, yaliyotumiwa kama nyenzo kuu ya usanifu wa kompyuta, ilianza kutoa njia kwa swichi za haraka, huku ikibaki moja ya chaguzi kuu za kuunganisha vifaa vya pembeni. Leo tairi, ambayo inaitwa Basi la Huduma ya Biashara (ESB), inaweza kucheza takriban nafasi sawa na Unibus, pamoja na faida zote, lakini kwa kiwango cha juu.

Matukio kwa kweli yanaendelea haraka. Mwaka mmoja tu uliopita, mmoja wa wachambuzi wakuu wa Kundi la Gartner, Efim Natis, alipendekeza yafuatayo: "Mojawapo ya njia kuu za kuunda miundombinu ya maombi ya biashara imejengwa kwa kutumia michakato iliyounganishwa bila usawa." Na katika makala ya InfoWorld ya Oktoba 2002 iliyoandikwa na John Udell, mtu angeweza kusoma: “Sasa kwa kuwa sote tunakubali kwamba huduma za Wavuti zinapaswa kuwasiliana kwa njia isiyolingana, imedhihirika wazi kwamba vifaa vya kati vinavyolenga ujumbe (vya kati vinavyolenga ujumbe, MOM) vinakuwa muhimu. ."

Kama unaweza kuona, katika mwaka mmoja tu, dhana iligeuka kuwa taarifa. Sonic Software, iliyoundwa na wahitimu kadhaa wa BEA Systems na leo inayotambuliwa kama mmoja wa viongozi katika ukuzaji wa vifaa vya kati, ilichukua jukumu kubwa katika kufanikisha hili. Kazi ya kuvutia sana imefanywa katika nyingine kadhaa makampuni madogo(kwa mfano, Collaxa), hata hivyo, Sonic alikuwa mmoja wa wa kwanza kutoa utekelezaji wake wa michakato ya asynchronous iliyounganishwa kwa uhuru. Licha ya mambo yote mapya, katika bidhaa yake ya programu ya SonicXQ ESB kampuni, kwa kweli, inatekeleza wazo la zamani la basi la kawaida, lililokopwa kutoka kwa kompyuta ndogo, lakini wakati huo huo linajumuisha katika sura mpya.

Katika kesi hii, ESB ni ya jumla kwa maana kwamba inaunganisha programu zote kwenye biashara. ESB, inayotekelezwa kwa kutumia SOA (Usanifu-Ulioelekezwa kwa Huduma), imeundwa kuunganisha maombi ya biashara kulingana na huduma za Wavuti zisizolingana na zinazozingatia hati na Usanifu wa Kiunganishi cha J2EE (JCA). Teknolojia hizi mbili hutoa uelekezaji wa ujumbe unaotegemea maudhui na hukuruhusu kupanga mwingiliano kati ya programu na kuunganisha usimamizi wa mchakato wa biashara kwa njia ambayo inawezekana kufanya bila madalali wa gharama kubwa.

Asili ya maendeleo ya SonicXQ ilivutia umakini mkubwa. Kihistoria, wakala wa ujumuishaji (wakati mwingine huitwa seva za ujumuishaji) walikuwa wa kwanza kuibuka. Ufumbuzi uliojengwa kwa misingi ya mawakala wa ushirikiano unaweza kuwakilishwa kwa namna ya swichi. Kwa msaada wao, metacomputer fulani ya dhahania huundwa, ambapo udhibiti wote umejengwa juu ya kanuni kuu. Matokeo yake ni kitu kama hyper- mainframe. Sonic ilifanya kitu sawa na DEC, ambayo ilitoa kompyuta ndogo za basi kama njia mbadala ya gharama nafuu kwa mifumo kuu miongo mitatu iliyopita; Suluhisho la Sonic hukuruhusu kuunda aina ya metacomputer kwa biashara nzima, lakini kwa gharama ya chini. Matokeo yake ni analog ya mini-metacomputer: badala ya kubadili gharama kubwa, basi ya Huduma ya Biashara hutolewa.

Teknolojia ya SonicXQ haikuonekana ghafla. Ana vyanzo viwili vinavyojulikana sana. Ya kwanza ni vifaa vya kati vinavyotokana na ujumbe. Aina hii ya seti ya zana za programu inakabiliwa na kuzaliwa upya kwa kweli, hasa kuhusiana na ujio wa Huduma ya Ujumbe wa Java kutoka kwa Mifumo midogo ya jua. Unaweza kusoma juu ya kile kinachotokea mbele hii, na kwa undani zaidi juu ya SonicMQ, mtangulizi wa SonicXQ, katika. Machapisho haya yote mawili yanasalia kuwa muhimu, lakini mazingira ya programu ya biashara yamebadilika sana katika mwaka uliopita, haswa na athari za huduma za Wavuti. Mwaka mmoja uliopita, wakati machapisho haya yanatayarishwa, wazo la huduma za Wavuti ni nini na umuhimu wao haukuwa wazi kabisa. Baada ya muda, hali imekuwa wazi sana, na huduma za Wavuti zinapaswa kutajwa kama chanzo cha pili cha SonicXQ.

Basi la Huduma ya Biashara

Miongoni mwa matukio ya mwaka uliopita, ni lazima ieleweke kwamba kitu kipya na kisicho kawaida kilionekana katika istilahi ya kitaaluma. Baadhi kutoka kambi ya Microsft/IBM wanaiita "orchestration" ya huduma za Wavuti; wengine kutoka kambi ya Sun/BEA wanaiita "choreography." Vita vya hivi punde zaidi katika vita vya viwango vinapamba moto juu ya jinsi bora ya kufanya programu za biashara kufanya kazi mara kwa mara kwa kutumia Huduma za Wavuti. Sababu ya shughuli mpya ni kwamba hatimaye ikawa wazi kwa kila mtu: katika hali ya sasa, uwezo wa maombi yaliyounganishwa sana umechoka, ugumu wa mifumo umekuwa mkubwa sana. Walakini, mpango asilia wa kusambaza huduma za Wavuti kwa kutumia hazina zilizojengwa kulingana na kiwango cha UDDI uligeuka kuwa wa matumizi kidogo kwa madhumuni ya ushirika. Wakati huo huo, huduma za Wavuti, na haswa matoleo yao yanayoelekezwa kwa hati isiyo ya kawaida, hutoa njia halisi ya kutoka kwa shida ngumu. Kutoka kwa mtazamo wa kiufundi, changamoto ya kujenga miundombinu ya maombi ya biashara kwa kutumia michakato ya asynchronous iliyounganishwa kwa urahisi ina masuluhisho kadhaa mbadala.

Enterprise Service Bus, iliyojengwa juu ya SonicXQ, ni mojawapo yao. Kwa msaada wa uti wa mgongo wa kampuni iliyoundwa na SonicXQ, usanifu uliosambazwa yenye mwelekeo wa huduma. ESB hukuruhusu kuunda vyombo vya kupangisha huduma. Huduma ni rahisi kukusanyika na kupanga kwa sababu huduma iliyo na vyombo na sehemu ya ESB inaonyeshwa kwa sehemu zingine za ESB. Aidha, muundo mzima ni virtual; mtandao halisi wa kimwili ambao "huishi" unaweza kuwa chini ya mabadiliko bila kupoteza utendaji.

Wakati wa uendeshaji wa ESB, huduma moja au zaidi zinazohusiana ziko kwenye chombo maalum (chombo cha huduma). Vyombo ni njia ya kuhamisha huduma kupitia mchakato uliosambazwa kulingana na njia za ujumbe. Utaratibu wa kupitisha ujumbe ni kama ifuatavyo. Ujumbe unatumwa kwa ingizo la basi la ESB. Hapa njia inaongezwa kwayo, ambayo inakuruhusu kupanga ukuzaji unaoendeshwa na maudhui kupitia mchakato uliosambazwa; mchakato huu una udhibiti wa ugatuzi. Kama sehemu ya mchakato huu, ujumbe husafiri kupitia huduma kadhaa ili kufikia sehemu ya mwisho ambapo hutolewa kutoka kwa chombo.

Majina ya kimantiki badala ya majina halisi yanaweza kutumika kubainisha ncha. Kuanzisha mawasiliano kati ya majina ya kimwili na mantiki (kuchora ramani) hufanywa na utaratibu maalum uliojumuishwa katika ESB. Kwa hivyo, uwezo wa uboreshaji umejengwa kwa asili katika usanifu; mfumo unaweza kubadilika bila kurekebisha kanuni au kuharibu michakato iliyopo ya biashara. Usanidi huruhusu viwango vingi vya Ubora wa Huduma (QoS) ili kuhakikisha upitishaji wa ujumbe unaotegemewa kati ya programu. Kwa ujumla, wakati ujumbe umekamilisha njia yake yote, huacha mwisho wa mpokeaji, na ujumbe unaothibitisha kupokelewa hutumwa kwa mtumaji. Faida ya mchakato wa kupitisha ujumbe unaotokana na ESB ni kwamba mantiki yake iko karibu sana na mawasiliano ya ulimwengu halisi.

Misingi: JCA na Huduma za Wavuti

Ujumuishaji wa maombi unaotolewa katika ESB unawezekana kwa ujio wa usanifu wa muunganisho wa JCA wa Sun Microsystems na SOAP, itifaki ya kawaida ya huduma za Wavuti. JCA, iliyoundwa mahsusi ili kushinda ugumu unaohusishwa na ujumuishaji wa programu, hutoa mbinu sanifu za kukamilisha kazi hii. Kampuni Mfumo wa habari, iliyojengwa kwa kanuni za JCA, hutumia kiolesura cha JDBC kufikia programu. Leo njia hii ni maarufu kabisa; Seva nyingi za kisasa za programu, ikiwa ni pamoja na BEA WebLogic na IBM WebSphere, zinaunga mkono adapta za JCA. Kwa kuongeza, watoa huduma wengi wa ufumbuzi wa kifurushi wanakusudia kusaidia JCA katika matoleo yajayo ya bidhaa zao.

Uhalisi wa matumizi ya huduma za Wavuti kwa SonicXQ unatokana na jinsi mchakato wa "orchestration" (au "choreography") unavyopangwa. Inategemea itifaki ya SOAP, lakini imefunikwa na umbizo la ujumbe rahisi na la hatari. Wakati huo huo, SonicXQ Enterprise Service Bus hutoa uoanifu na modeli ya hati ya SOAP isiyolingana (hati modeli isiyolingana) na modeli ya SOAP iliyosawazishwa, iliyojengwa juu ya kanuni ya simu za utaratibu wa mbali (RPC). Katika SonicXQ, huduma zimeelezewa kwa Lugha ya WSDL, lakini WSDL imeunganishwa moja kwa moja na Mfumo wa Uchakataji Uliosambazwa. Kama matokeo, huduma inaweza au isisajiliwe katika saraka ya nje ya UDDI ikiwa sio lazima.

Bila kutilia chumvi yoyote, teknolojia ya SonicXQ inaweza kuitwa kuwa kali: inachanganya idadi ya mitindo ya kisasa katika kompyuta ya shirika. Lakini labda jambo la kufurahisha zaidi ni kwamba inakupa ufahamu bora wa huduma za Wavuti ni nini. Na sio kwa maneno, lakini kwa vitendo.

Fasihi

1. Leonid Chernyak. IOM, kuzaliwa upya //

2. Valery Kor zhov. Postman kwa maombi //

3. Stuart J. Johnston, Huduma za Wavuti Vita huchukua zamu ya Kisanaa. Choreography au orchestration? XML Magazine, 2002, No. 10/11