BPM ശൈലി സംയോജനം

ഹലോ, ഹബ്ർ!

ERP-ക്ലാസ് സോഫ്‌റ്റ്‌വെയർ സൊല്യൂഷനുകൾ വികസിപ്പിക്കുന്നതിൽ ഞങ്ങളുടെ കമ്പനി പ്രത്യേകം ശ്രദ്ധിക്കുന്നു, അതിൽ സിംഹഭാഗവും ഇടപാട് സംവിധാനങ്ങളാൽ വ്യാപൃതരാണ്. ഞങ്ങളുടെ ഉൽപ്പന്നങ്ങളുടെ ആധുനിക പതിപ്പുകൾ JavaEE സാങ്കേതികവിദ്യകളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്, എന്നാൽ ഞങ്ങൾ മൈക്രോസർവീസുകളും സജീവമായി പരീക്ഷിക്കുന്നു. അത്തരം പരിഹാരങ്ങളുടെ ഏറ്റവും പ്രശ്നകരമായ മേഖലകളിലൊന്ന് അടുത്തുള്ള ഡൊമെയ്‌നുകളുമായി ബന്ധപ്പെട്ട വിവിധ സബ്സിസ്റ്റങ്ങളുടെ സംയോജനമാണ്. നമ്മൾ ഉപയോഗിക്കുന്ന വാസ്തുവിദ്യാ ശൈലികൾ, ടെക്നോളജി സ്റ്റാക്കുകൾ, ചട്ടക്കൂടുകൾ എന്നിവ പരിഗണിക്കാതെ തന്നെ ഇന്റഗ്രേഷൻ ടാസ്‌ക്കുകൾ എല്ലായ്പ്പോഴും ഞങ്ങൾക്ക് വലിയ തലവേദനയാണ് നൽകുന്നത്, എന്നാൽ അടുത്തിടെ അത്തരം പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിൽ പുരോഗതി ഉണ്ടായിട്ടുണ്ട്.

നിങ്ങളുടെ ശ്രദ്ധയിൽപ്പെടുത്തിയ ലേഖനത്തിൽ, നിയുക്ത പ്രദേശത്ത് എൻ‌പി‌ഒ ക്രിസ്റ്റയുടെ അനുഭവത്തെയും വാസ്തുവിദ്യാ ഗവേഷണത്തെയും കുറിച്ച് ഞാൻ സംസാരിക്കും. ഒരു ആപ്ലിക്കേഷൻ ഡെവലപ്പറുടെ വീക്ഷണകോണിൽ നിന്ന് ഒരു സംയോജന പ്രശ്നത്തിനുള്ള ലളിതമായ പരിഹാരത്തിന്റെ ഒരു ഉദാഹരണം ഞങ്ങൾ പരിഗണിക്കുകയും ഈ ലാളിത്യത്തിന് പിന്നിൽ എന്താണ് മറഞ്ഞിരിക്കുന്നതെന്ന് കണ്ടെത്തുകയും ചെയ്യും.

എ

ലേഖനത്തിൽ വിവരിച്ചിരിക്കുന്ന വാസ്തുവിദ്യയും സാങ്കേതികവുമായ പരിഹാരങ്ങൾ നിർദ്ദിഷ്ട ജോലികളുടെ പശ്ചാത്തലത്തിൽ വ്യക്തിപരമായ അനുഭവത്തെ അടിസ്ഥാനമാക്കി ഞാൻ വാഗ്ദാനം ചെയ്യുന്നു. ഈ പരിഹാരങ്ങൾ സാർവത്രികമാണെന്ന് അവകാശപ്പെടുന്നില്ല, മറ്റ് ഉപയോഗ വ്യവസ്ഥകളിൽ ഇത് അനുയോജ്യമല്ലായിരിക്കാം.

ബിപിഎമ്മിന് ഇതുമായി എന്ത് ബന്ധമുണ്ട്?

ഈ ചോദ്യത്തിന് ഉത്തരം നൽകാൻ, ഞങ്ങളുടെ പരിഹാരങ്ങളുടെ പ്രായോഗിക പ്രശ്നങ്ങളുടെ പ്രത്യേകതകളിലേക്ക് അൽപ്പം പരിശോധിക്കേണ്ടതുണ്ട്. ഉപയോക്തൃ ഇന്റർഫേസുകളിലൂടെ ഡാറ്റാബേസിലേക്കുള്ള ഡാറ്റാ എൻട്രി, ഈ ഡാറ്റയുടെ മാനുവൽ, ഓട്ടോമേറ്റഡ് വെരിഫിക്കേഷൻ, ചില വർക്ക്ഫ്ലോകളിലൂടെ കടന്നുപോകുക, മറ്റൊരു സിസ്റ്റം / അനലിറ്റിക്കൽ ഡാറ്റാബേസ് / ആർക്കൈവ്, റിപ്പോർട്ടുകൾ സൃഷ്ടിക്കൽ എന്നിവയാണ് ഞങ്ങളുടെ സാധാരണ ഇടപാട് സംവിധാനത്തിലെ ബിസിനസ് ലോജിക്കിന്റെ പ്രധാന ഭാഗം. അതിനാൽ, ഉപഭോക്താക്കൾക്കുള്ള സിസ്റ്റത്തിന്റെ പ്രധാന പ്രവർത്തനം അവരുടെ ആന്തരിക ബിസിനസ്സ് പ്രക്രിയകളുടെ ഓട്ടോമേഷൻ ആണ്.

സൗകര്യാർത്ഥം, ഞങ്ങൾ ആശയവിനിമയത്തിൽ "ഡോക്യുമെന്റ്" എന്ന പദം ഉപയോഗിക്കുന്നത് ഒരു പ്രത്യേക വർക്ക്ഫ്ലോ "അറ്റാച്ചുചെയ്യാൻ" കഴിയുന്ന ഒരു പൊതുവായ കീ ഉപയോഗിച്ച് ഏകീകരിക്കപ്പെട്ട ഒരു ഡാറ്റാ സെറ്റിന്റെ ചില സംഗ്രഹമായാണ്.
എന്നാൽ ഏകീകരണ യുക്തിയുടെ കാര്യമോ? എല്ലാത്തിനുമുപരി, സംയോജനത്തിന്റെ ചുമതല സൃഷ്ടിക്കുന്നത് സിസ്റ്റത്തിന്റെ വാസ്തുവിദ്യയാണ്, അത് ഉപഭോക്താവിന്റെ അഭ്യർത്ഥന മാനിച്ചല്ല, മറിച്ച് തികച്ചും വ്യത്യസ്തമായ ഘടകങ്ങളുടെ സ്വാധീനത്തിലാണ് ഭാഗങ്ങളായി “വീഴുന്നത്”:

• കോൺവെയുടെ നിയമത്തിന്റെ സ്വാധീനത്തിൽ;
• മറ്റ് ഉൽപ്പന്നങ്ങൾക്കായി മുമ്പ് വികസിപ്പിച്ച സബ്സിസ്റ്റങ്ങളുടെ പുനരുപയോഗത്തിന്റെ ഫലമായി;
• നോൺ-ഫങ്ഷണൽ ആവശ്യകതകളെ അടിസ്ഥാനമാക്കി ആർക്കിടെക്റ്റ് തീരുമാനിച്ചത്.

ഇന്റഗ്രേഷൻ ആർട്ടിഫാക്‌റ്റുകൾ ഉപയോഗിച്ച് ബിസിനസ്സ് ലോജിക്കിനെ മലിനമാക്കാതിരിക്കാനും സിസ്റ്റത്തിന്റെ വാസ്തുവിദ്യാ ലാൻഡ്‌സ്‌കേപ്പിന്റെ പ്രത്യേകതകൾ പരിശോധിക്കുന്നതിൽ നിന്ന് ആപ്ലിക്കേഷൻ ഡെവലപ്പറെ രക്ഷിക്കാതിരിക്കാനും ഇന്റഗ്രേഷൻ ലോജിക്കിനെ പ്രധാന വർക്ക്ഫ്ലോയുടെ ബിസിനസ്സ് ലോജിക്കിൽ നിന്ന് വേർതിരിക്കാനുള്ള വലിയ പ്രലോഭനമുണ്ട്. ഈ സമീപനത്തിന് നിരവധി ഗുണങ്ങളുണ്ട്, പക്ഷേ പരിശീലനം അതിന്റെ കാര്യക്ഷമതയില്ലായ്മ കാണിക്കുന്നു:

• പ്രധാന വർക്ക്ഫ്ലോ നടപ്പിലാക്കുന്നതിലെ പരിമിതമായ എക്സ്റ്റൻഷൻ പോയിന്റുകൾ കാരണം സമന്വയ കോളുകളുടെ രൂപത്തിലുള്ള ഏറ്റവും ലളിതമായ ഓപ്ഷനുകളിലേക്ക് സാധാരണയായി ഏകീകരണ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നു (താഴെയുള്ള സിൻക്രണസ് ഇന്റഗ്രേഷന്റെ പോരായ്മകളെക്കുറിച്ച് കൂടുതൽ);
• മറ്റൊരു ഉപസിസ്റ്റത്തിൽ നിന്നുള്ള ഫീഡ്‌ബാക്ക് ആവശ്യമായി വരുമ്പോൾ ഇന്റഗ്രേഷൻ ആർട്ടിഫാക്‌റ്റുകൾ ഇപ്പോഴും പ്രധാന ബിസിനസ്സ് ലോജിക്കിലേക്ക് തുളച്ചുകയറുന്നു;
• ആപ്ലിക്കേഷൻ ഡെവലപ്പർ സംയോജനത്തെ അവഗണിക്കുകയും വർക്ക്ഫ്ലോ മാറ്റുന്നതിലൂടെ അത് എളുപ്പത്തിൽ തകർക്കാൻ കഴിയും;
• ഉപയോക്താവിന്റെ വീക്ഷണകോണിൽ നിന്ന് സിസ്റ്റം ഒരൊറ്റ മൊത്തത്തിൽ അവസാനിക്കുന്നു, ഉപസിസ്റ്റങ്ങൾക്കിടയിലുള്ള "സീമുകൾ" ശ്രദ്ധേയമാകുന്നു, അനാവശ്യമായ ഉപയോക്തൃ പ്രവർത്തനങ്ങൾ ദൃശ്യമാകുന്നു, അത് ഒരു സബ്സിസ്റ്റത്തിൽ നിന്ന് മറ്റൊന്നിലേക്ക് ഡാറ്റ കൈമാറ്റം ആരംഭിക്കുന്നു.

പ്രധാന ബിസിനസ്സ് ലോജിക്കിന്റെയും വർക്ക്ഫ്ലോയുടെയും അവിഭാജ്യ ഘടകമായി സംയോജന ഇടപെടലുകളെ പരിഗണിക്കുക എന്നതാണ് മറ്റൊരു സമീപനം. ആപ്ലിക്കേഷൻ ഡെവലപ്പർമാരുടെ നൈപുണ്യ ആവശ്യകതകൾ ഉയരുന്നതിൽ നിന്ന് നിലനിർത്തുന്നതിന്, പുതിയ സംയോജന ഇടപെടലുകൾ സൃഷ്ടിക്കുന്നത് എളുപ്പത്തിലും സ്വാഭാവികമായും, ഒരു പരിഹാരം തിരഞ്ഞെടുക്കുന്നതിനുള്ള കുറഞ്ഞ ഓപ്ഷനുകളോടെ ചെയ്യണം. ഇത് കാണുന്നതിനേക്കാൾ ബുദ്ധിമുട്ടാണ്: ഉപകരണം അതിന്റെ ഉപയോഗത്തിന് ആവശ്യമായ വൈവിധ്യമാർന്ന ഓപ്ഷനുകൾ ഉപയോക്താവിന് നൽകുന്നതിന് ശക്തമായിരിക്കണം, അതേ സമയം തന്നെ കാലിൽ വെടിവയ്ക്കാൻ അനുവദിക്കരുത്. ഇന്റഗ്രേഷൻ ടാസ്‌ക്കുകളുടെ പശ്ചാത്തലത്തിൽ ഒരു എഞ്ചിനീയർ ഉത്തരം നൽകേണ്ട നിരവധി ചോദ്യങ്ങളുണ്ട്, എന്നാൽ ഒരു ആപ്ലിക്കേഷൻ ഡെവലപ്പർ അവരുടെ ദൈനംദിന ജോലിയിൽ ചിന്തിക്കാൻ പാടില്ലാത്ത നിരവധി ചോദ്യങ്ങളുണ്ട്: ഇടപാട് അതിരുകൾ, സ്ഥിരത, ആറ്റോമിസിറ്റി, സുരക്ഷ, സ്കെയിലിംഗ്, ലോഡ് ആൻഡ് റിസോഴ്സ് ഡിസ്ട്രിബ്യൂഷൻ, റൂട്ടിംഗ്, മാർഷലിംഗ്, പ്രചാരണവും സ്വിച്ചിംഗ് സന്ദർഭങ്ങളും മുതലായവ. ആപ്ലിക്കേഷൻ ഡവലപ്പർമാർക്ക് വളരെ ലളിതമായ തീരുമാന ടെംപ്ലേറ്റുകൾ നൽകേണ്ടത് ആവശ്യമാണ്, അത്തരം ചോദ്യങ്ങൾക്കെല്ലാം ഉത്തരം ഇതിനകം മറച്ചിരിക്കുന്നു. ഈ പാറ്റേണുകൾ വേണ്ടത്ര സുരക്ഷിതമായിരിക്കണം: ബിസിനസ്സ് ലോജിക് പലപ്പോഴും മാറുന്നു, ഇത് പിശകുകൾ അവതരിപ്പിക്കാനുള്ള സാധ്യത വർദ്ധിപ്പിക്കുന്നു, പിശകുകളുടെ വില വളരെ താഴ്ന്ന നിലയിലായിരിക്കണം.

എന്നിട്ടും, ബിപിഎമ്മിന് ഇതുമായി എന്ത് ബന്ധമുണ്ട്? വർക്ക്ഫ്ലോ നടപ്പിലാക്കുന്നതിന് നിരവധി ഓപ്ഷനുകൾ ഉണ്ട് ...
തീർച്ചയായും, ബിസിനസ്സ് പ്രക്രിയകളുടെ മറ്റൊരു നിർവ്വഹണം ഞങ്ങളുടെ പരിഹാരങ്ങളിൽ വളരെ ജനപ്രിയമാണ് - സ്റ്റേറ്റ് ട്രാൻസിഷൻ ഡയഗ്രാമിന്റെ ഡിക്ലറേറ്റീവ് ക്രമീകരണത്തിലൂടെയും ബിസിനസ് ലോജിക് ഉപയോഗിച്ച് ഹാൻഡ്‌ലർമാരെ സംക്രമണങ്ങളിലേക്ക് ബന്ധിപ്പിക്കുന്നതിലൂടെയും. അതേ സമയം, ബിസിനസ്സ് പ്രക്രിയയിൽ "പ്രമാണത്തിന്റെ" നിലവിലെ സ്ഥാനം നിർണ്ണയിക്കുന്ന സംസ്ഥാനം "പ്രമാണത്തിന്റെ" തന്നെ ഒരു ആട്രിബ്യൂട്ട് ആണ്.

പ്രോജക്റ്റിന്റെ തുടക്കത്തിൽ ഈ പ്രക്രിയ ഇങ്ങനെയാണ്

ലീനിയർ ബിസിനസ്സ് പ്രക്രിയകൾ സൃഷ്ടിക്കുന്നതിന്റെ ആപേക്ഷിക ലാളിത്യവും വേഗതയുമാണ് അത്തരമൊരു നടപ്പാക്കലിന്റെ ജനപ്രീതിക്ക് കാരണം. എന്നിരുന്നാലും, സോഫ്‌റ്റ്‌വെയർ സംവിധാനങ്ങൾ കൂടുതൽ സങ്കീർണ്ണമാകുമ്പോൾ, ബിസിനസ്സ് പ്രക്രിയയുടെ ഓട്ടോമേറ്റഡ് ഭാഗം വളരുകയും കൂടുതൽ സങ്കീർണ്ണമാവുകയും ചെയ്യുന്നു. വിഘടിപ്പിക്കൽ, പ്രക്രിയകളുടെ ഭാഗങ്ങളുടെ പുനരുപയോഗം, ഫോർക്കിംഗ് പ്രക്രിയകൾ എന്നിവ ആവശ്യമാണ്, അങ്ങനെ ഓരോ ശാഖയും സമാന്തരമായി നടപ്പിലാക്കുന്നു. അത്തരം സാഹചര്യങ്ങളിൽ, ഉപകരണം അസൗകര്യത്തിലാകുന്നു, കൂടാതെ സ്റ്റേറ്റ് ട്രാൻസിഷൻ ഡയഗ്രം അതിന്റെ വിവര ഉള്ളടക്കം നഷ്‌ടപ്പെടുത്തുന്നു (ഇന്റഗ്രേഷൻ ഇടപെടലുകൾ ഡയഗ്രാമിൽ പ്രതിഫലിക്കുന്നില്ല).

ആവശ്യകതകൾ വ്യക്തമാക്കുന്ന നിരവധി ആവർത്തനങ്ങൾക്ക് ശേഷം ഈ പ്രക്രിയ ഇങ്ങനെയാണ് കാണപ്പെടുന്നത്

ഈ അവസ്ഥയിൽ നിന്നുള്ള വഴി എഞ്ചിന്റെ സംയോജനമായിരുന്നു jBPM ഏറ്റവും സങ്കീർണ്ണമായ ബിസിനസ്സ് പ്രക്രിയകളുള്ള ചില ഉൽപ്പന്നങ്ങളിലേക്ക്. ഹ്രസ്വകാലത്തേക്ക്, ഈ പരിഹാരം കുറച്ച് വിജയിച്ചു: നൊട്ടേഷനിൽ തികച്ചും വിവരദായകവും കാലികവുമായ ഡയഗ്രം നിലനിർത്തിക്കൊണ്ട് സങ്കീർണ്ണമായ ബിസിനസ്സ് പ്രക്രിയകൾ നടപ്പിലാക്കാൻ സാധിച്ചു. BPMN2.

സങ്കീർണ്ണമായ ബിസിനസ്സ് പ്രക്രിയയുടെ ഒരു ചെറിയ ഭാഗം

ദീർഘകാലാടിസ്ഥാനത്തിൽ, പരിഹാരം പ്രതീക്ഷകൾക്ക് അനുസൃതമായി പ്രവർത്തിച്ചില്ല: വിഷ്വൽ ടൂളുകൾ വഴി ബിസിനസ്സ് പ്രക്രിയകൾ സൃഷ്ടിക്കുന്നതിന്റെ ഉയർന്ന തൊഴിൽ തീവ്രത സ്വീകാര്യമായ ഉൽപ്പാദനക്ഷമത സൂചകങ്ങൾ കൈവരിക്കാൻ അനുവദിച്ചില്ല, കൂടാതെ ഉപകരണം തന്നെ ഡവലപ്പർമാർക്കിടയിൽ ഏറ്റവും ഇഷ്ടപ്പെടാത്ത ഒന്നായി മാറി. എഞ്ചിന്റെ ആന്തരിക ഘടനയെക്കുറിച്ചും പരാതികൾ ഉണ്ടായിരുന്നു, ഇത് നിരവധി "പാച്ചുകൾ", "ക്രച്ചുകൾ" എന്നിവയുടെ രൂപത്തിലേക്ക് നയിച്ചു.

jBPM ഉപയോഗിക്കുന്നതിന്റെ പ്രധാന പോസിറ്റീവ് വശം, ഒരു ബിസിനസ് പ്രോസസ് ഉദാഹരണത്തിനായി അതിന്റേതായ സ്ഥിരതയുള്ള അവസ്ഥയുടെ നേട്ടങ്ങളും ദോഷങ്ങളും തിരിച്ചറിയുകയായിരുന്നു. സിഗ്നലുകളിലൂടെയും സന്ദേശങ്ങളിലൂടെയും അസിൻക്രണസ് ഇടപെടലുകൾ ഉപയോഗിച്ച് വ്യത്യസ്ത ആപ്ലിക്കേഷനുകൾക്കിടയിൽ സങ്കീർണ്ണമായ സംയോജന പ്രോട്ടോക്കോളുകൾ നടപ്പിലാക്കാൻ ഒരു പ്രോസസ്സ് സമീപനം ഉപയോഗിക്കുന്നതിനുള്ള സാധ്യതയും ഞങ്ങൾ കണ്ടു. സ്ഥിരമായ ഒരു സംസ്ഥാനത്തിന്റെ സാന്നിധ്യം ഇതിൽ നിർണായക പങ്ക് വഹിക്കുന്നു.

മേൽപ്പറഞ്ഞവയെ അടിസ്ഥാനമാക്കി, നമുക്ക് നിഗമനം ചെയ്യാം: ബി‌പി‌എം ശൈലിയിലുള്ള പ്രോസസ്സ് സമീപനം, കൂടുതൽ സങ്കീർണ്ണമായ ബിസിനസ്സ് പ്രക്രിയകൾ ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനും ഈ പ്രക്രിയകളിലേക്ക് സംയോജന പ്രവർത്തനങ്ങൾ സമന്വയിപ്പിക്കുന്നതിനും അനുയോജ്യമായ ഒരു നൊട്ടേഷനിൽ നടപ്പിലാക്കിയ പ്രക്രിയ ദൃശ്യപരമായി പ്രദർശിപ്പിക്കാനുള്ള കഴിവ് നിലനിർത്തുന്നതിനുമുള്ള വിപുലമായ ജോലികൾ പരിഹരിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നു.

ഒരു ഏകീകരണ പാറ്റേൺ എന്ന നിലയിൽ സിൻക്രണസ് കോളുകളുടെ പോരായ്മകൾ

സിൻക്രണസ് ഇന്റഗ്രേഷൻ ഏറ്റവും ലളിതമായ തടയൽ കോളിനെ സൂചിപ്പിക്കുന്നു. ഒരു സബ്സിസ്റ്റം സെർവർ വശമായി പ്രവർത്തിക്കുകയും ആവശ്യമുള്ള രീതി ഉപയോഗിച്ച് API വെളിപ്പെടുത്തുകയും ചെയ്യുന്നു. മറ്റൊരു സബ്സിസ്റ്റം ഒരു ക്ലയന്റ് സൈഡ് ആയി പ്രവർത്തിക്കുന്നു, ശരിയായ സമയത്ത്, ഒരു ഫലം പ്രതീക്ഷിച്ച് ഒരു കോൾ ചെയ്യുന്നു. സിസ്റ്റത്തിന്റെ ആർക്കിടെക്ചറിനെ ആശ്രയിച്ച്, ക്ലയന്റ്, സെർവർ വശങ്ങൾ ഒരേ ആപ്ലിക്കേഷനിലും പ്രക്രിയയിലും അല്ലെങ്കിൽ വ്യത്യസ്തമായവയിലും ഹോസ്റ്റുചെയ്യാനാകും. രണ്ടാമത്തെ സാഹചര്യത്തിൽ, നിങ്ങൾ ആർ‌പി‌സിയുടെ ചില നിർവ്വഹണങ്ങൾ പ്രയോഗിക്കുകയും പാരാമീറ്ററുകളുടെ മാർഷലിംഗും കോളിന്റെ ഫലവും നൽകുകയും വേണം.

അത്തരമൊരു സംയോജന പാറ്റേണിന് വളരെ വലിയ പോരായ്മകളുണ്ട്, പക്ഷേ അതിന്റെ ലാളിത്യം കാരണം ഇത് പ്രായോഗികമായി വളരെ വ്യാപകമായി ഉപയോഗിക്കുന്നു. നടപ്പാക്കലിന്റെ വേഗത നിങ്ങളെ ആകർഷിക്കുകയും "കത്തുന്ന" സമയപരിധിയുടെ സാഹചര്യങ്ങളിൽ ഇത് വീണ്ടും വീണ്ടും പ്രയോഗിക്കുകയും സാങ്കേതിക കടത്തിലേക്ക് പരിഹാരം എഴുതുകയും ചെയ്യുന്നു. എന്നാൽ അനുഭവപരിചയമില്ലാത്ത ഡെവലപ്പർമാർ ഇത് അബോധാവസ്ഥയിൽ ഉപയോഗിക്കുന്നു, നെഗറ്റീവ് പരിണതഫലങ്ങൾ മനസ്സിലാക്കാതെ.

ഉപസിസ്റ്റങ്ങളുടെ കണക്റ്റിവിറ്റിയിലെ ഏറ്റവും വ്യക്തമായ വർദ്ധനവിന് പുറമേ, "സ്പ്രെഡിംഗ്", "സ്ട്രെച്ചിംഗ്" ഇടപാടുകൾ എന്നിവയിൽ വ്യക്തമായ പ്രശ്നങ്ങൾ കുറവാണ്. തീർച്ചയായും, ബിസിനസ്സ് ലോജിക് എന്തെങ്കിലും മാറ്റങ്ങൾ വരുത്തുകയാണെങ്കിൽ, ഇടപാടുകൾ ഒഴിച്ചുകൂടാനാവാത്തതാണ്, കൂടാതെ ഇടപാടുകൾ, ഈ മാറ്റങ്ങൾ ബാധിച്ച ചില ആപ്ലിക്കേഷൻ ഉറവിടങ്ങൾ ലോക്ക് ചെയ്യുന്നു. അതായത്, ഒരു സബ്സിസ്റ്റം മറ്റൊന്നിൽ നിന്നുള്ള പ്രതികരണത്തിനായി കാത്തിരിക്കുന്നതുവരെ, ഇടപാട് പൂർത്തിയാക്കാനും ലോക്കുകൾ റിലീസ് ചെയ്യാനും അതിന് കഴിയില്ല. ഇത് വിവിധ ഇഫക്റ്റുകളുടെ അപകടസാധ്യത ഗണ്യമായി വർദ്ധിപ്പിക്കുന്നു:

• സിസ്റ്റം പ്രതികരണശേഷി നഷ്ടപ്പെട്ടു, അഭ്യർത്ഥനകൾക്കുള്ള ഉത്തരങ്ങൾക്കായി ഉപയോക്താക്കൾ വളരെക്കാലം കാത്തിരിക്കുന്നു;
• നിറഞ്ഞു കവിയുന്ന ത്രെഡ് പൂൾ കാരണം സെർവർ സാധാരണയായി ഉപയോക്തൃ അഭ്യർത്ഥനകളോട് പ്രതികരിക്കുന്നത് നിർത്തുന്നു: ഇടപാട് കൈവശപ്പെടുത്തിയിരിക്കുന്ന റിസോഴ്സിന്റെ ലോക്കിൽ മിക്ക ത്രെഡുകളും "നിലക്കുന്നു";
• ഡെഡ്‌ലോക്കുകൾ പ്രത്യക്ഷപ്പെടാൻ തുടങ്ങുന്നു: അവ സംഭവിക്കാനുള്ള സാധ്യത ഇടപാടുകളുടെ ദൈർഘ്യം, ബിസിനസ്സ് ലോജിക്കിന്റെ അളവ്, ഇടപാടിൽ ഉൾപ്പെട്ടിരിക്കുന്ന ലോക്കുകൾ എന്നിവയെ ആശ്രയിച്ചിരിക്കുന്നു;
• ഇടപാട് കാലഹരണപ്പെടൽ പിശകുകൾ ദൃശ്യമാകുന്നു;
• ടാസ്‌ക്കിന് വലിയ അളവിലുള്ള ഡാറ്റ പ്രോസസ്സ് ചെയ്യാനും മാറ്റാനും ആവശ്യമുണ്ടെങ്കിൽ സെർവർ OutOfMemory-ൽ "വീഴുന്നു", കൂടാതെ സിൻക്രണസ് ഇന്റഗ്രേഷനുകളുടെ സാന്നിധ്യം പ്രോസസ്സിംഗിനെ "ലൈറ്റർ" ഇടപാടുകളായി വിഭജിക്കുന്നത് വളരെ പ്രയാസകരമാക്കുന്നു.

ഒരു വാസ്തുവിദ്യാ വീക്ഷണകോണിൽ, സംയോജന സമയത്ത് കോളുകൾ തടയുന്നത് വ്യക്തിഗത സബ്സിസ്റ്റങ്ങളുടെ ഗുണനിലവാര നിയന്ത്രണം നഷ്ടപ്പെടുന്നതിലേക്ക് നയിക്കുന്നു: മറ്റൊരു സബ്സിസ്റ്റത്തിന്റെ ഗുണനിലവാര സൂചകങ്ങളിൽ നിന്ന് ഒറ്റപ്പെട്ട് ഒരു സബ്സിസ്റ്റത്തിന് ഗുണനിലവാര ലക്ഷ്യങ്ങൾ കൈവരിക്കുന്നത് അസാധ്യമാണ്. വ്യത്യസ്ത ടീമുകൾ ഉപസിസ്റ്റങ്ങൾ വികസിപ്പിച്ചെടുത്താൽ, ഇത് ഒരു വലിയ പ്രശ്നമാണ്.

സംയോജിപ്പിച്ചിരിക്കുന്ന സബ്സിസ്റ്റങ്ങൾ വ്യത്യസ്ത ആപ്ലിക്കേഷനുകളിലാണെങ്കിൽ, ഇരുവശത്തും സിൻക്രണസ് മാറ്റങ്ങൾ വരുത്തേണ്ടതുണ്ടെങ്കിൽ കാര്യങ്ങൾ കൂടുതൽ രസകരമാകും. ഈ മാറ്റങ്ങൾ എങ്ങനെ ഇടപാടുകാരാക്കാം?

പ്രത്യേക ഇടപാടുകളിൽ മാറ്റങ്ങൾ വരുത്തിയാൽ, ശക്തമായ ഒഴിവാക്കൽ കൈകാര്യം ചെയ്യലും നഷ്ടപരിഹാരവും നൽകേണ്ടതുണ്ട്, ഇത് സമന്വയ സംയോജനങ്ങളുടെ പ്രധാന നേട്ടം പൂർണ്ണമായും ഇല്ലാതാക്കുന്നു - ലാളിത്യം.

വിതരണം ചെയ്ത ഇടപാടുകളും ഓർമ്മയിൽ വരുന്നു, പക്ഷേ ഞങ്ങളുടെ പരിഹാരങ്ങളിൽ ഞങ്ങൾ അവ ഉപയോഗിക്കുന്നില്ല: വിശ്വാസ്യത ഉറപ്പാക്കാൻ പ്രയാസമാണ്.

ഇടപാടുകളുടെ പ്രശ്നത്തിനുള്ള പരിഹാരമായി "സാഗ"

മൈക്രോസർവീസുകളുടെ വർദ്ധിച്ചുവരുന്ന ജനപ്രീതിക്കൊപ്പം, വർദ്ധിച്ചുവരുന്ന ആവശ്യകതയുണ്ട് സാഗ പാറ്റേൺ.

ഈ പാറ്റേൺ ദൈർഘ്യമേറിയ ഇടപാടുകളുടെ മേൽപ്പറഞ്ഞ പ്രശ്നങ്ങൾ പരിപൂർണ്ണമായി പരിഹരിക്കുന്നു, കൂടാതെ ബിസിനസ്സ് ലോജിക്കിന്റെ വശത്ത് നിന്ന് സിസ്റ്റത്തിന്റെ അവസ്ഥ കൈകാര്യം ചെയ്യുന്നതിനുള്ള സാധ്യതകൾ വികസിപ്പിക്കുകയും ചെയ്യുന്നു: വിജയിക്കാത്ത ഇടപാടിന് ശേഷമുള്ള നഷ്ടപരിഹാരം സിസ്റ്റത്തെ അതിന്റെ യഥാർത്ഥ അവസ്ഥയിലേക്ക് മാറ്റില്ല, പക്ഷേ ഒരു ബദൽ നൽകുന്നു. ഡാറ്റ പ്രോസസ്സിംഗ് റൂട്ട്. നിങ്ങൾ പ്രോസസ്സ് "നല്ല" അവസാനത്തിലേക്ക് കൊണ്ടുവരാൻ ശ്രമിക്കുമ്പോൾ വിജയകരമായി പൂർത്തിയാക്കിയ ഡാറ്റ പ്രോസസ്സിംഗ് ഘട്ടങ്ങൾ ആവർത്തിക്കാതിരിക്കാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

രസകരമെന്നു പറയട്ടെ, മോണോലിത്തിക്ക് സിസ്റ്റങ്ങളിൽ, അയഞ്ഞ കപ്പിൾഡ് സബ്സിസ്റ്റങ്ങളുടെ സംയോജനത്തിന്റെ കാര്യത്തിലും ഈ പാറ്റേൺ പ്രസക്തമാണ്, കൂടാതെ ദൈർഘ്യമേറിയ ഇടപാടുകളും അനുബന്ധ റിസോഴ്സ് ലോക്കുകളും മൂലമുണ്ടാകുന്ന നെഗറ്റീവ് ഇഫക്റ്റുകൾ ഉണ്ട്.

ബി‌പി‌എം ശൈലിയിലുള്ള ഞങ്ങളുടെ ബിസിനസ്സ് പ്രക്രിയകളെ സംബന്ധിച്ചിടത്തോളം, സാഗസ് നടപ്പിലാക്കുന്നത് വളരെ എളുപ്പമാണെന്ന് മാറുന്നു: സാഗസിന്റെ വ്യക്തിഗത ഘട്ടങ്ങൾ ബിസിനസ്സ് പ്രക്രിയയ്ക്കുള്ളിലെ പ്രവർത്തനങ്ങളായി സജ്ജീകരിക്കാം, കൂടാതെ ബിസിനസ്സ് പ്രക്രിയയുടെ സ്ഥിരമായ അവസ്ഥ നിർണ്ണയിക്കുന്നു. മറ്റ് കാര്യങ്ങൾ, സാഗസിന്റെ ആന്തരിക അവസ്ഥ. അതായത്, ഞങ്ങൾക്ക് അധിക ഏകോപന സംവിധാനം ആവശ്യമില്ല. ഗതാഗതമെന്ന നിലയിൽ "ഒരിക്കലെങ്കിലും" ഗ്യാരണ്ടികൾക്കുള്ള പിന്തുണയുള്ള ഒരു സന്ദേശ ബ്രോക്കർ മാത്രമാണ് നിങ്ങൾക്ക് വേണ്ടത്.

എന്നാൽ അത്തരമൊരു പരിഹാരത്തിന് അതിന്റേതായ "വില" ഉണ്ട്:

• ബിസിനസ്സ് യുക്തി കൂടുതൽ സങ്കീർണ്ണമാകുന്നു: നിങ്ങൾ നഷ്ടപരിഹാരം നൽകേണ്ടതുണ്ട്;
• പൂർണ്ണമായ സ്ഥിരത ഉപേക്ഷിക്കേണ്ടത് ആവശ്യമാണ്, ഇത് മോണോലിത്തിക്ക് സിസ്റ്റങ്ങൾക്ക് പ്രത്യേകിച്ച് സെൻസിറ്റീവ് ആയിരിക്കും;
• വാസ്തുവിദ്യ കുറച്ചുകൂടി സങ്കീർണ്ണമായിത്തീരുന്നു, ഒരു സന്ദേശ ബ്രോക്കറുടെ അധിക ആവശ്യമുണ്ട്;
• അധിക മോണിറ്ററിംഗ്, അഡ്മിനിസ്ട്രേഷൻ ടൂളുകൾ ആവശ്യമായി വരും (പൊതുവേ ഇത് നല്ലതാണെങ്കിലും: സിസ്റ്റം സേവനത്തിന്റെ ഗുണനിലവാരം വർദ്ധിക്കും).

മോണോലിത്തിക്ക് സിസ്റ്റങ്ങൾക്ക്, "സാഗ്സ്" ഉപയോഗിക്കുന്നതിനുള്ള ന്യായീകരണം അത്ര വ്യക്തമല്ല. മൈക്രോസർവീസുകൾക്കും മറ്റ് SOA-കൾക്കും, മിക്കവാറും, ഇതിനകം തന്നെ ഒരു ബ്രോക്കർ ഉണ്ട്, കൂടാതെ പ്രോജക്റ്റിന്റെ തുടക്കത്തിൽ പൂർണ്ണമായ സ്ഥിരത ത്യജിക്കപ്പെട്ടിട്ടുണ്ട്, ഈ പാറ്റേൺ ഉപയോഗിക്കുന്നതിന്റെ പ്രയോജനങ്ങൾ ദോഷങ്ങളെ മറികടക്കും, പ്രത്യേകിച്ചും സൗകര്യപ്രദമായ API ഉണ്ടെങ്കിൽ ബിസിനസ് ലോജിക് ലെവൽ.

മൈക്രോസർവീസുകളിലെ ബിസിനസ് ലോജിക്കിന്റെ എൻക്യാപ്‌സുലേഷൻ

ഞങ്ങൾ മൈക്രോസർവീസുകളിൽ പരീക്ഷണം തുടങ്ങിയപ്പോൾ, ന്യായമായ ഒരു ചോദ്യം ഉയർന്നു: ഡൊമെയ്ൻ ഡാറ്റ പെർസിസ്റ്റൻസ് നൽകുന്ന സേവനവുമായി ബന്ധപ്പെട്ട് ഡൊമെയ്ൻ ബിസിനസ് ലോജിക് എവിടെ സ്ഥാപിക്കണം?

വിവിധ BPMS കളുടെ ആർക്കിടെക്ചർ നോക്കുമ്പോൾ, സ്ഥിരതയിൽ നിന്ന് ബിസിനസ്സ് ലോജിക് വേർതിരിക്കുന്നത് ന്യായമാണെന്ന് തോന്നിയേക്കാം: ഡൊമെയ്ൻ ബിസിനസ്സ് ലോജിക് നടപ്പിലാക്കുന്നതിനുള്ള പരിസ്ഥിതിയും കണ്ടെയ്നറും രൂപപ്പെടുത്തുന്ന പ്ലാറ്റ്ഫോമിന്റെയും ഡൊമെയ്ൻ-സ്വതന്ത്ര മൈക്രോസർവീസുകളുടെയും ഒരു പാളി സൃഷ്ടിക്കുക, കൂടാതെ ഡൊമെയ്ൻ ഡാറ്റ പെർസിസ്റ്റൻസ് ഒരു പ്രത്യേകമായി ക്രമീകരിക്കുക. വളരെ ലളിതവും ഭാരം കുറഞ്ഞതുമായ മൈക്രോസർവീസുകളുടെ പാളി. ഈ കേസിലെ ബിസിനസ്സ് പ്രക്രിയകൾ പെർസിസ്റ്റൻസ് ലെയറിന്റെ സേവനങ്ങൾ ക്രമീകരിക്കുന്നു.

ഈ സമീപനത്തിന് വളരെ വലിയ പ്ലസ് ഉണ്ട്: നിങ്ങൾക്ക് ഇഷ്ടമുള്ളത്ര പ്ലാറ്റ്ഫോമിന്റെ പ്രവർത്തനം വർദ്ധിപ്പിക്കാൻ കഴിയും, കൂടാതെ പ്ലാറ്റ്ഫോം മൈക്രോസർവീസുകളുടെ അനുബന്ധ പാളി മാത്രമേ ഇതിൽ നിന്ന് "കൊഴുപ്പ്" ലഭിക്കൂ. ഏത് ഡൊമെയ്‌നിൽ നിന്നുമുള്ള ബിസിനസ്സ് പ്രോസസ്സുകൾക്ക് പ്ലാറ്റ്‌ഫോമിന്റെ പുതിയ പ്രവർത്തനം അപ്‌ഡേറ്റ് ചെയ്‌തയുടൻ അത് ഉപയോഗിക്കാനുള്ള അവസരം ഉടനടി ലഭിക്കും.

കൂടുതൽ വിശദമായ പഠനം ഈ സമീപനത്തിന്റെ കാര്യമായ പോരായ്മകൾ വെളിപ്പെടുത്തി:

• ഒരേസമയം നിരവധി ഡൊമെയ്‌നുകളുടെ ബിസിനസ്സ് ലോജിക് നടപ്പിലാക്കുന്ന ഒരു പ്ലാറ്റ്‌ഫോം സേവനം പരാജയത്തിന്റെ ഒരൊറ്റ പോയിന്റായി വലിയ അപകടസാധ്യതകൾ വഹിക്കുന്നു. ബിസിനസ്സ് ലോജിക്കിലെ പതിവ് മാറ്റങ്ങൾ സിസ്റ്റം-വൈഡ് പരാജയങ്ങളിലേക്ക് നയിക്കുന്ന ബഗുകളുടെ അപകടസാധ്യത വർദ്ധിപ്പിക്കുന്നു;
• പ്രകടന പ്രശ്നങ്ങൾ: ഇടുങ്ങിയതും വേഗത കുറഞ്ഞതുമായ ഇന്റർഫേസിലൂടെ ബിസിനസ്സ് ലോജിക് അതിന്റെ ഡാറ്റയുമായി പ്രവർത്തിക്കുന്നു:
  • ഡാറ്റ വീണ്ടും മാർഷൽ ചെയ്യുകയും നെറ്റ്‌വർക്ക് സ്റ്റാക്കിലൂടെ പമ്പ് ചെയ്യുകയും ചെയ്യും;
  • സേവനത്തിന്റെ എക്‌സ്‌റ്റേണൽ എപിഐയുടെ തലത്തിലുള്ള അപര്യാപ്തമായ അന്വേഷണ പാരാമീറ്ററൈസേഷൻ കഴിവുകൾ കാരണം, പ്രോസസ്സിംഗിനായി ബിസിനസ് ലോജിക് ആവശ്യപ്പെടുന്നതിനേക്കാൾ കൂടുതൽ ഡാറ്റ ഡൊമെയ്‌ൻ സേവനം പലപ്പോഴും തിരികെ നൽകും;
  • നിരവധി സ്വതന്ത്ര ബിസിനസ്സ് ലോജിക്കുകൾക്ക് ഒരേ ഡാറ്റ പ്രോസസ്സിംഗിനായി ആവർത്തിച്ച് അഭ്യർത്ഥിക്കാൻ കഴിയും (ഡാറ്റ കാഷെ ചെയ്യുന്ന സെഷൻ ബീൻസ് ചേർത്തുകൊണ്ട് നിങ്ങൾക്ക് ഈ പ്രശ്നം ലഘൂകരിക്കാനാകും, എന്നാൽ ഇത് ആർക്കിടെക്ചറിനെ കൂടുതൽ സങ്കീർണ്ണമാക്കുകയും ഡാറ്റയുടെ പുതുമയുടെയും കാഷെ അസാധുവാക്കലിന്റെയും പ്രശ്നങ്ങൾ സൃഷ്ടിക്കുകയും ചെയ്യുന്നു);
• ഇടപാട് പ്രശ്നങ്ങൾ:
  • പ്ലാറ്റ്‌ഫോം സേവനം സംഭരിച്ച സ്ഥിരസ്ഥിതിയുള്ള ബിസിനസ്സ് പ്രക്രിയകൾ ഡൊമെയ്ൻ ഡാറ്റയുമായി പൊരുത്തപ്പെടുന്നില്ല, മാത്രമല്ല ഈ പ്രശ്നം പരിഹരിക്കാൻ എളുപ്പവഴികളൊന്നുമില്ല;
  • ഇടപാടിൽ നിന്ന് ഡൊമെയ്ൻ ഡാറ്റയുടെ ലോക്ക് നീക്കുന്നു: ഡൊമെയ്ൻ ബിസിനസ്സ് ലോജിക്ക് മാറ്റങ്ങൾ വരുത്തണമെങ്കിൽ, ആദ്യം യഥാർത്ഥ ഡാറ്റയുടെ കൃത്യത പരിശോധിച്ച ശേഷം, പ്രോസസ്സ് ചെയ്ത ഡാറ്റയിൽ മത്സരാധിഷ്ഠിത മാറ്റത്തിനുള്ള സാധ്യത ഒഴിവാക്കേണ്ടത് ആവശ്യമാണ്. ഡാറ്റയുടെ ബാഹ്യ തടയൽ പ്രശ്നം പരിഹരിക്കാൻ സഹായിക്കും, എന്നാൽ അത്തരമൊരു പരിഹാരം അധിക അപകടസാധ്യതകൾ വഹിക്കുകയും സിസ്റ്റത്തിന്റെ മൊത്തത്തിലുള്ള വിശ്വാസ്യത കുറയ്ക്കുകയും ചെയ്യുന്നു;
• അപ്ഡേറ്റ് ചെയ്യുമ്പോൾ കൂടുതൽ സങ്കീർണതകൾ: ചില സന്ദർഭങ്ങളിൽ, നിങ്ങൾ സ്ഥിരത സേവനവും ബിസിനസ് ലോജിക്കും സമന്വയിപ്പിച്ചോ കർശനമായ ക്രമത്തിലോ അപ്ഡേറ്റ് ചെയ്യേണ്ടതുണ്ട്.

അവസാനം, എനിക്ക് അടിസ്ഥാനകാര്യങ്ങളിലേക്ക് മടങ്ങേണ്ടിവന്നു: ഡൊമെയ്ൻ ഡാറ്റയും ഡൊമെയ്ൻ ബിസിനസ് ലോജിക്കും ഒരു മൈക്രോസർവീസിലേക്ക് കൂട്ടിച്ചേർക്കുക. ഈ സമീപനം സിസ്റ്റത്തിലെ ഒരു അവിഭാജ്യ ഘടകമായി മൈക്രോസർവീസിനെക്കുറിച്ചുള്ള ധാരണയെ ലളിതമാക്കുന്നു, മാത്രമല്ല മുകളിൽ പറഞ്ഞ പ്രശ്നങ്ങൾക്ക് കാരണമാകില്ല. ഇതും സൗജന്യമല്ല:

• ബിസിനസ്സ് ലോജിക്കും (പ്രത്യേകിച്ച്, ബിസിനസ് പ്രക്രിയകളുടെ ഭാഗമായി ഉപയോക്തൃ പ്രവർത്തനങ്ങൾ നൽകുന്നതിന്) API പ്ലാറ്റ്ഫോം സേവനങ്ങളുമായുള്ള ആശയവിനിമയത്തിന് API സ്റ്റാൻഡേർഡൈസേഷൻ ആവശ്യമാണ്; API മാറ്റങ്ങളിൽ കൂടുതൽ ശ്രദ്ധാപൂർവമായ ശ്രദ്ധ, മുന്നോട്ടും പിന്നോട്ടും അനുയോജ്യത ആവശ്യമാണ്;
• അത്തരം ഓരോ മൈക്രോസർവീസിന്റെയും ഭാഗമായി ബിസിനസ് ലോജിക്കിന്റെ പ്രവർത്തനം ഉറപ്പാക്കാൻ അധിക റൺടൈം ലൈബ്രറികൾ ചേർക്കേണ്ടത് ആവശ്യമാണ്, ഇത് അത്തരം ലൈബ്രറികൾക്ക് പുതിയ ആവശ്യകതകൾക്ക് കാരണമാകുന്നു: ലഘുത്വവും കുറഞ്ഞ ട്രാൻസിറ്റീവ് ഡിപൻഡൻസികളും;
• ബിസിനസ് ലോജിക് ഡെവലപ്പർമാർ ലൈബ്രറി പതിപ്പുകളുടെ ട്രാക്ക് സൂക്ഷിക്കേണ്ടതുണ്ട്: ഒരു മൈക്രോ സർവീസ് വളരെക്കാലമായി അന്തിമമാക്കിയിട്ടില്ലെങ്കിൽ, അതിൽ മിക്കവാറും ലൈബ്രറികളുടെ കാലഹരണപ്പെട്ട പതിപ്പ് അടങ്ങിയിരിക്കാം. ഇത് ഒരു പുതിയ ഫീച്ചർ ചേർക്കുന്നതിന് ഒരു അപ്രതീക്ഷിത തടസ്സമാകാം, കൂടാതെ പതിപ്പുകൾക്കിടയിൽ പൊരുത്തപ്പെടാത്ത മാറ്റങ്ങളുണ്ടെങ്കിൽ അത്തരം ഒരു സേവനത്തിന്റെ പഴയ ബിസിനസ്സ് ലോജിക്ക് ലൈബ്രറികളുടെ പുതിയ പതിപ്പുകളിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യേണ്ടതായി വന്നേക്കാം.

അത്തരം ഒരു ആർക്കിടെക്ചറിൽ പ്ലാറ്റ്ഫോം സേവനങ്ങളുടെ ഒരു പാളി കൂടിയുണ്ട്, എന്നാൽ ഈ ലെയർ ഇനിമുതൽ ഡൊമെയ്ൻ ബിസിനസ്സ് ലോജിക് എക്സിക്യൂട്ട് ചെയ്യുന്നതിനുള്ള ഒരു കണ്ടെയ്നർ രൂപപ്പെടുത്തുന്നില്ല, മറിച്ച് അതിന്റെ പരിസ്ഥിതി മാത്രം, സഹായ "പ്ലാറ്റ്ഫോം" ഫംഗ്ഷനുകൾ നൽകുന്നു. ഡൊമെയ്ൻ മൈക്രോസർവീസുകളുടെ ലഘുത്വം നിലനിർത്താൻ മാത്രമല്ല, മാനേജ്മെന്റ് കേന്ദ്രീകൃതമാക്കാനും അത്തരമൊരു പാളി ആവശ്യമാണ്.

ഉദാഹരണത്തിന്, ബിസിനസ്സ് പ്രക്രിയകളിലെ ഉപയോക്തൃ പ്രവർത്തനങ്ങൾ ടാസ്‌ക്കുകൾ സൃഷ്ടിക്കുന്നു. എന്നിരുന്നാലും, ടാസ്‌ക്കുകളിൽ പ്രവർത്തിക്കുമ്പോൾ, പൊതുവായ ലിസ്റ്റിലെ എല്ലാ ഡൊമെയ്‌നുകളിൽ നിന്നുമുള്ള ടാസ്‌ക്കുകൾ ഉപയോക്താവ് കാണണം, അതിനർത്ഥം ഡൊമെയ്‌ൻ ബിസിനസ്സ് ലോജിക്കിൽ നിന്ന് മായ്‌ച്ച ഉചിതമായ ടാസ്‌ക് രജിസ്‌ട്രേഷൻ പ്ലാറ്റ്‌ഫോം സേവനം ഉണ്ടായിരിക്കണം എന്നാണ്. ഈ സന്ദർഭത്തിൽ ബിസിനസ്സ് ലോജിക്കിന്റെ സംഗ്രഹം നിലനിർത്തുന്നത് തികച്ചും പ്രശ്നകരമാണ്, ഇത് ഈ വാസ്തുവിദ്യയുടെ മറ്റൊരു വിട്ടുവീഴ്ചയാണ്.

ഒരു ആപ്ലിക്കേഷൻ ഡെവലപ്പറുടെ കണ്ണിലൂടെയുള്ള ബിസിനസ്സ് പ്രക്രിയകളുടെ സംയോജനം

മുകളിൽ സൂചിപ്പിച്ചതുപോലെ, നല്ല വികസന ഉൽപ്പാദനക്ഷമത കണക്കാക്കാൻ നിരവധി ആപ്ലിക്കേഷനുകളുടെ ഇടപെടൽ നടപ്പിലാക്കുന്നതിന്റെ സാങ്കേതിക, എഞ്ചിനീയറിംഗ് സവിശേഷതകളിൽ നിന്ന് ആപ്ലിക്കേഷൻ ഡവലപ്പർ സംഗ്രഹിച്ചിരിക്കണം.

ലേഖനത്തിനായി പ്രത്യേകം കണ്ടുപിടിച്ച സങ്കീർണ്ണമായ ഒരു സംയോജന പ്രശ്നം പരിഹരിക്കാൻ ശ്രമിക്കാം. ഇത് മൂന്ന് ആപ്ലിക്കേഷനുകൾ ഉൾപ്പെടുന്ന ഒരു "ഗെയിം" ടാസ്ക് ആയിരിക്കും, അവയിൽ ഓരോന്നും ചില ഡൊമെയ്ൻ നാമങ്ങൾ നിർവചിക്കുന്നു: "app1", "app2", "app3".

ഓരോ ആപ്ലിക്കേഷനിലും, ഇന്റഗ്രേഷൻ ബസിലൂടെ "പന്ത് കളിക്കാൻ" തുടങ്ങുന്ന ബിസിനസ്സ് പ്രക്രിയകൾ സമാരംഭിക്കുന്നു. "ബോൾ" എന്ന് പേരിട്ടിരിക്കുന്ന സന്ദേശങ്ങൾ പന്തായി പ്രവർത്തിക്കും.

ഗെയിമിന്റെ നിയമങ്ങൾ:

• ആദ്യ കളിക്കാരൻ തുടക്കക്കാരനാണ്. അവൻ മറ്റ് കളിക്കാരെ ഗെയിമിലേക്ക് ക്ഷണിക്കുന്നു, ഗെയിം ആരംഭിക്കുന്നു, എപ്പോൾ വേണമെങ്കിലും അത് അവസാനിപ്പിക്കാം;
• മറ്റ് കളിക്കാർ ഗെയിമിൽ തങ്ങളുടെ പങ്കാളിത്തം പ്രഖ്യാപിക്കുന്നു, പരസ്പരം "പരിചയപ്പെടുക" ആദ്യ കളിക്കാരൻ;
• പന്ത് ലഭിച്ച ശേഷം, കളിക്കാരൻ മറ്റൊരു പങ്കെടുക്കുന്ന കളിക്കാരനെ തിരഞ്ഞെടുത്ത് പന്ത് അവനു കൈമാറുന്നു. പാസുകളുടെ ആകെ എണ്ണം കണക്കാക്കുന്നു;
• ഓരോ കളിക്കാരനും "ഊർജ്ജം" ഉണ്ട്, അത് ആ കളിക്കാരന്റെ ഓരോ പന്ത് പാസ്സിലും കുറയുന്നു. ഊർജം തീർന്നാൽ, കളിക്കാരൻ വിരമിക്കൽ പ്രഖ്യാപിച്ച് ഗെയിമിൽ നിന്ന് പുറത്താക്കപ്പെടുന്നു;
• കളിക്കാരൻ തനിച്ചാണെങ്കിൽ, അവൻ ഉടൻ തന്നെ തന്റെ പുറപ്പെടൽ പ്രഖ്യാപിക്കുന്നു;
• എല്ലാ കളിക്കാരും പുറത്താകുമ്പോൾ, ആദ്യ കളിക്കാരൻ കളിയുടെ അവസാനം പ്രഖ്യാപിക്കുന്നു. അവൻ നേരത്തെ ഗെയിം ഉപേക്ഷിച്ചെങ്കിൽ, അത് പൂർത്തിയാക്കാൻ ഗെയിം പിന്തുടരുന്നത് തുടരും.

ഈ പ്രശ്നം പരിഹരിക്കുന്നതിന്, ബിസിനസ്സ് പ്രക്രിയകൾക്കായി ഞാൻ ഞങ്ങളുടെ DSL ഉപയോഗിക്കും, ഇത് കുറഞ്ഞത് ഒരു ബോയിലർപ്ലേറ്റ് ഉപയോഗിച്ച് കോട്ട്ലിനിലെ യുക്തിയെ ഒതുക്കമുള്ള രീതിയിൽ വിവരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

app1 ആപ്ലിക്കേഷനിൽ, ആദ്യ കളിക്കാരന്റെ (അവൻ ഗെയിമിന്റെ തുടക്കക്കാരനും) ബിസിനസ്സ് പ്രക്രിയ പ്രവർത്തിക്കും:

ക്ലാസ് ഇനീഷ്യൽ പ്ലെയർ

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.constraint.UniqueConstraints
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.dsl.taskOperation
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList : ArrayList<PlayerInfo>()

// Это класс экземпляра процесса: инкапсулирует его внутреннее состояние
class InitialPlayer : ProcessImpl<InitialPlayer>(initialPlayerModel) {
    var playerName: String by persistent("Player1")
    var energy: Int by persistent(30)
    var players: PlayersList by persistent(PlayersList())
    var shotCounter: Int = 0
}

// Это декларация модели процесса: создается один раз, используется всеми
// экземплярами процесса соответствующего класса
val initialPlayerModel = processModel<InitialPlayer>(name = "InitialPlayer",
                                                     version = 1) {

    // По правилам, первый игрок является инициатором игры и должен быть единственным
    uniqueConstraint = UniqueConstraints.singleton

    // Объявляем активности, из которых состоит бизнес-процесс
    val sendNewGameSignal = signal<String>("NewGame")
    val sendStopGameSignal = signal<String>("StopGame")
    val startTask = humanTask("Start") {
        taskOperation {
            processCondition { players.size > 0 }
            confirmation { "Подключилось ${players.size} игроков. Начинаем?" }
        }
    }
    val stopTask = humanTask("Stop") {
        taskOperation {}
    }
    val waitPlayerJoin = signalWait<String>("PlayerJoin") { signal ->
        players.add(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... join player ${signal.data} ...")
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... player ${signal.data} is out ...")
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val throwStartBall = messageSend<Int>("Ball") {
        messageData = { 1 }
        activation = { selectNextPlayer() }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    // Теперь конструируем граф процесса из объявленных активностей
    startFrom(sendNewGameSignal)
            .fork("mainFork") {
                next(startTask)
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut)
                        .branch("checkPlayers") {
                            ifTrue { players.isEmpty() }
                                    .next(sendStopGameSignal)
                                    .terminate()
                            ifElse().next(waitPlayerOut)
                        }
            }
    startTask.fork("afterStart") {
        next(throwStartBall)
                .branch("mainLoop") {
                    ifTrue { energy < 5 }.next(sendPlayerOut).next(waitBall)
                    ifElse().next(waitBall).next(throwBall).loop()
                }
        next(stopTask).next(sendStopGameSignal)
    }

    // Навешаем на активности дополнительные обработчики для логирования
    sendNewGameSignal.onExit { println("Let's play!") }
    sendStopGameSignal.onExit { println("Stop!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<InitialPlayer, Int>.selectNextPlayer() {
    val player = process.players.random()
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

ബിസിനസ്സ് ലോജിക് എക്സിക്യൂട്ട് ചെയ്യുന്നതിനു പുറമേ, മുകളിലെ കോഡിന് ഒരു ബിസിനസ് പ്രക്രിയയുടെ ഒബ്ജക്റ്റ് മോഡൽ നിർമ്മിക്കാൻ കഴിയും, അത് ഒരു ഡയഗ്രമായി ദൃശ്യമാക്കാൻ കഴിയും. ഞങ്ങൾ ഇതുവരെ വിഷ്വലൈസർ നടപ്പിലാക്കിയിട്ടില്ല, അതിനാൽ ഞങ്ങൾക്ക് കുറച്ച് സമയം വരയ്ക്കേണ്ടി വന്നു (മുകളിലുള്ള കോഡ് ഉപയോഗിച്ച് ഡയഗ്രാമിന്റെ സ്ഥിരത മെച്ചപ്പെടുത്തുന്നതിന് ഗേറ്റുകളുടെ ഉപയോഗം സംബന്ധിച്ച ബിപിഎംഎൻ നൊട്ടേഷൻ ഞാൻ ചെറുതായി ലളിതമാക്കി):

app2 മറ്റൊരു കളിക്കാരന്റെ ബിസിനസ്സ് പ്രക്രിയ ഉൾപ്പെടും:

ക്ലാസ് റാൻഡം പ്ലെയർ

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RandomPlayer : ProcessImpl<RandomPlayer>(randomPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RandomPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val randomPlayerModel = processModel<RandomPlayer>(name = "RandomPlayer", 
                                                   version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!,
                    signal.sender.domain,
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RandomPlayer, Int>.selectNextPlayer() {
    val player = if (process.players.isNotEmpty()) 
        process.players.random() 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

ഡയഗ്രം:

app3 ആപ്ലിക്കേഷനിൽ, ഞങ്ങൾ കളിക്കാരനെ അൽപ്പം വ്യത്യസ്ത സ്വഭാവമുള്ളയാളാക്കും: അടുത്ത കളിക്കാരനെ ക്രമരഹിതമായി തിരഞ്ഞെടുക്കുന്നതിനുപകരം, അവൻ റൗണ്ട്-റോബിൻ അൽഗോരിതം അനുസരിച്ച് പ്രവർത്തിക്കും:

ക്ലാസ് RoundRobinPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RoundRobinPlayer : ProcessImpl<RoundRobinPlayer>(roundRobinPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RoundRobinPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var nextPlayerIndex: Int by persistent(-1)
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val roundRobinPlayerModel = processModel<RoundRobinPlayer>(
        name = "RoundRobinPlayer", 
        version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!, 
                    signal.sender.domain, 
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!, 
                signal.sender.domain, 
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RoundRobinPlayer, Int>.selectNextPlayer() {
    var idx = process.nextPlayerIndex + 1
    if (idx >= process.players.size) {
        idx = 0
    }
    process.nextPlayerIndex = idx
    val player = if (process.players.isNotEmpty()) 
        process.players[idx] 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

അല്ലെങ്കിൽ, കളിക്കാരന്റെ പെരുമാറ്റം മുമ്പത്തേതിൽ നിന്ന് വ്യത്യസ്തമല്ല, അതിനാൽ ഡയഗ്രം മാറില്ല.

എല്ലാം പ്രവർത്തിപ്പിക്കാൻ ഇപ്പോൾ നമുക്ക് ഒരു ടെസ്റ്റ് ആവശ്യമാണ്. ഒരു ബോയിലർ പ്ലേറ്റ് ഉപയോഗിച്ച് ലേഖനം അലങ്കോലപ്പെടുത്താതിരിക്കാൻ ഞാൻ ടെസ്റ്റിന്റെ കോഡ് മാത്രമേ നൽകൂ (വാസ്തവത്തിൽ, മറ്റ് ബിസിനസ്സ് പ്രക്രിയകളുടെ സംയോജനം പരിശോധിക്കുന്നതിന് മുമ്പ് സൃഷ്ടിച്ച പരീക്ഷണ അന്തരീക്ഷം ഞാൻ ഉപയോഗിച്ചു):

ടെസ്റ്റ് ഗെയിം()

@Test
public void testGame() throws InterruptedException {
    String pl2 = startProcess(app2, "RandomPlayer", playerParams("Player2", 20));
    String pl3 = startProcess(app2, "RandomPlayer", playerParams("Player3", 40));
    String pl4 = startProcess(app3, "RoundRobinPlayer", playerParams("Player4", 25));
    String pl5 = startProcess(app3, "RoundRobinPlayer", playerParams("Player5", 35));
    String pl1 = startProcess(app1, "InitialPlayer");
    // Теперь нужно немного подождать, пока игроки "познакомятся" друг с другом.
    // Ждать через sleep - плохое решение, зато самое простое. 
    // Не делайте так в серьезных тестах!
    Thread.sleep(1000);
    // Запускаем игру, закрывая пользовательскую активность
    assertTrue(closeTask(app1, pl1, "Start"));
    app1.getWaiting().waitProcessFinished(pl1);
    app2.getWaiting().waitProcessFinished(pl2);
    app2.getWaiting().waitProcessFinished(pl3);
    app3.getWaiting().waitProcessFinished(pl4);
    app3.getWaiting().waitProcessFinished(pl5);
}

private Map<String, Object> playerParams(String name, int energy) {
    Map<String, Object> params = new HashMap<>();
    params.put("playerName", name);
    params.put("energy", energy);
    return params;
}

ടെസ്റ്റ് പ്രവർത്തിപ്പിക്കുക, ലോഗ് നോക്കുക:

കൺസോൾ ഔട്ട്പുട്ട്

Взята блокировка ключа lock://app1/process/InitialPlayer
Let's play!
Снята блокировка ключа lock://app1/process/InitialPlayer
Player2: I'm here!
Player3: I'm here!
Player4: I'm here!
Player5: I'm here!
... join player Player2 ...
... join player Player4 ...
... join player Player3 ...
... join player Player5 ...
Step 1: Player1 >>> Player3
Step 2: Player3 >>> Player5
Step 3: Player5 >>> Player3
Step 4: Player3 >>> Player4
Step 5: Player4 >>> Player3
Step 6: Player3 >>> Player4
Step 7: Player4 >>> Player5
Step 8: Player5 >>> Player2
Step 9: Player2 >>> Player5
Step 10: Player5 >>> Player4
Step 11: Player4 >>> Player2
Step 12: Player2 >>> Player4
Step 13: Player4 >>> Player1
Step 14: Player1 >>> Player4
Step 15: Player4 >>> Player3
Step 16: Player3 >>> Player1
Step 17: Player1 >>> Player2
Step 18: Player2 >>> Player3
Step 19: Player3 >>> Player1
Step 20: Player1 >>> Player5
Step 21: Player5 >>> Player1
Step 22: Player1 >>> Player2
Step 23: Player2 >>> Player4
Step 24: Player4 >>> Player5
Step 25: Player5 >>> Player3
Step 26: Player3 >>> Player4
Step 27: Player4 >>> Player2
Step 28: Player2 >>> Player5
Step 29: Player5 >>> Player2
Step 30: Player2 >>> Player1
Step 31: Player1 >>> Player3
Step 32: Player3 >>> Player4
Step 33: Player4 >>> Player1
Step 34: Player1 >>> Player3
Step 35: Player3 >>> Player4
Step 36: Player4 >>> Player3
Step 37: Player3 >>> Player2
Step 38: Player2 >>> Player5
Step 39: Player5 >>> Player4
Step 40: Player4 >>> Player5
Step 41: Player5 >>> Player1
Step 42: Player1 >>> Player5
Step 43: Player5 >>> Player3
Step 44: Player3 >>> Player5
Step 45: Player5 >>> Player2
Step 46: Player2 >>> Player3
Step 47: Player3 >>> Player2
Step 48: Player2 >>> Player5
Step 49: Player5 >>> Player4
Step 50: Player4 >>> Player2
Step 51: Player2 >>> Player5
Step 52: Player5 >>> Player1
Step 53: Player1 >>> Player5
Step 54: Player5 >>> Player3
Step 55: Player3 >>> Player5
Step 56: Player5 >>> Player2
Step 57: Player2 >>> Player1
Step 58: Player1 >>> Player4
Step 59: Player4 >>> Player1
Step 60: Player1 >>> Player4
Step 61: Player4 >>> Player3
Step 62: Player3 >>> Player2
Step 63: Player2 >>> Player5
Step 64: Player5 >>> Player4
Step 65: Player4 >>> Player5
Step 66: Player5 >>> Player1
Step 67: Player1 >>> Player5
Step 68: Player5 >>> Player3
Step 69: Player3 >>> Player4
Step 70: Player4 >>> Player2
Step 71: Player2 >>> Player5
Step 72: Player5 >>> Player2
Step 73: Player2 >>> Player1
Step 74: Player1 >>> Player4
Step 75: Player4 >>> Player1
Step 76: Player1 >>> Player2
Step 77: Player2 >>> Player5
Step 78: Player5 >>> Player4
Step 79: Player4 >>> Player3
Step 80: Player3 >>> Player1
Step 81: Player1 >>> Player5
Step 82: Player5 >>> Player1
Step 83: Player1 >>> Player4
Step 84: Player4 >>> Player5
Step 85: Player5 >>> Player3
Step 86: Player3 >>> Player5
Step 87: Player5 >>> Player2
Step 88: Player2 >>> Player3
Player2: I'm out!
Step 89: Player3 >>> Player4
... player Player2 is out ...
Step 90: Player4 >>> Player1
Step 91: Player1 >>> Player3
Step 92: Player3 >>> Player1
Step 93: Player1 >>> Player4
Step 94: Player4 >>> Player3
Step 95: Player3 >>> Player5
Step 96: Player5 >>> Player1
Step 97: Player1 >>> Player5
Step 98: Player5 >>> Player3
Step 99: Player3 >>> Player5
Step 100: Player5 >>> Player4
Step 101: Player4 >>> Player5
Player4: I'm out!
... player Player4 is out ...
Step 102: Player5 >>> Player1
Step 103: Player1 >>> Player3
Step 104: Player3 >>> Player1
Step 105: Player1 >>> Player3
Step 106: Player3 >>> Player5
Step 107: Player5 >>> Player3
Step 108: Player3 >>> Player1
Step 109: Player1 >>> Player3
Step 110: Player3 >>> Player5
Step 111: Player5 >>> Player1
Step 112: Player1 >>> Player3
Step 113: Player3 >>> Player5
Step 114: Player5 >>> Player3
Step 115: Player3 >>> Player1
Step 116: Player1 >>> Player3
Step 117: Player3 >>> Player5
Step 118: Player5 >>> Player1
Step 119: Player1 >>> Player3
Step 120: Player3 >>> Player5
Step 121: Player5 >>> Player3
Player5: I'm out!
... player Player5 is out ...
Step 122: Player3 >>> Player5
Step 123: Player5 >>> Player1
Player5: I'm out!
Step 124: Player1 >>> Player3
... player Player5 is out ...
Step 125: Player3 >>> Player1
Step 126: Player1 >>> Player3
Player1: I'm out!
... player Player1 is out ...
Step 127: Player3 >>> Player3
Player3: I'm out!
Step 128: Player3 >>> Player3
... player Player3 is out ...
Player3: I'm out!
Stop!
Step 129: Player3 >>> Player3
Player3: I'm out!

ഇതിൽ നിന്നെല്ലാം നിരവധി സുപ്രധാന നിഗമനങ്ങളിൽ എത്തിച്ചേരാനാകും:

• ആവശ്യമായ ഉപകരണങ്ങൾ ലഭ്യമാണെങ്കിൽ, ആപ്ലിക്കേഷൻ ഡെവലപ്പർമാർക്ക് ബിസിനസ്സ് യുക്തിയിൽ നിന്ന് വിട്ടുനിൽക്കാതെ ആപ്ലിക്കേഷനുകൾക്കിടയിൽ സംയോജന ഇടപെടലുകൾ സൃഷ്ടിക്കാൻ കഴിയും;
• എഞ്ചിനീയറിംഗ് കഴിവുകൾ ആവശ്യമുള്ള ഒരു സംയോജന ചുമതലയുടെ സങ്കീർണ്ണത (സങ്കീർണ്ണത) ചട്ടക്കൂടിന്റെ ആർക്കിടെക്ചറിൽ ആദ്യം സ്ഥാപിച്ചിട്ടുണ്ടെങ്കിൽ ചട്ടക്കൂടിനുള്ളിൽ മറയ്ക്കാൻ കഴിയും. ചുമതലയുടെ ബുദ്ധിമുട്ട് (ബുദ്ധിമുട്ട്) മറയ്ക്കാൻ കഴിയില്ല, അതിനാൽ കോഡിലെ ബുദ്ധിമുട്ടുള്ള ഒരു ജോലിയുടെ പരിഹാരം അതിനനുസരിച്ച് നോക്കും;
• ഇന്റഗ്രേഷൻ ലോജിക് വികസിപ്പിക്കുമ്പോൾ, എല്ലാ സംയോജന പങ്കാളികളുടെയും സംസ്ഥാന മാറ്റത്തിന്റെ സ്ഥിരതയും രേഖീയവൽക്കരണത്തിന്റെ അഭാവവും കണക്കിലെടുക്കേണ്ടത് ആവശ്യമാണ്. ബാഹ്യസംഭവങ്ങൾ സംഭവിക്കുന്ന ക്രമത്തോട് യുക്തിരഹിതമാക്കുന്നതിന് യുക്തിയെ സങ്കീർണ്ണമാക്കാൻ ഇത് നമ്മെ പ്രേരിപ്പിക്കുന്നു. ഞങ്ങളുടെ ഉദാഹരണത്തിൽ, കളിക്കാരൻ ഗെയിമിൽ നിന്ന് പുറത്തുകടക്കുന്നതായി പ്രഖ്യാപിച്ചതിന് ശേഷം ഗെയിമിൽ പങ്കെടുക്കാൻ നിർബന്ധിതനാകുന്നു: അവന്റെ എക്സിറ്റിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ എത്തുന്നതുവരെ മറ്റ് കളിക്കാർ അദ്ദേഹത്തിന് പന്ത് കൈമാറുന്നത് തുടരുകയും എല്ലാ പങ്കാളികളും പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യും. ഈ ലോജിക് ഗെയിമിന്റെ നിയമങ്ങളിൽ നിന്ന് പിന്തുടരുന്നില്ല കൂടാതെ തിരഞ്ഞെടുത്ത വാസ്തുവിദ്യയുടെ ചട്ടക്കൂടിനുള്ളിൽ ഒരു വിട്ടുവീഴ്ച പരിഹാരമാണ്.

അടുത്തതായി, ഞങ്ങളുടെ പരിഹാരത്തിന്റെ വിവിധ സൂക്ഷ്മതകൾ, വിട്ടുവീഴ്ചകൾ, മറ്റ് പോയിന്റുകൾ എന്നിവയെക്കുറിച്ച് സംസാരിക്കാം.

എല്ലാ സന്ദേശങ്ങളും ഒരു ക്യൂവിൽ

എല്ലാ സംയോജിത ആപ്ലിക്കേഷനുകളും ഒരു ഇന്റഗ്രേഷൻ ബസ് ഉപയോഗിച്ചാണ് പ്രവർത്തിക്കുന്നത്, അത് ഒരു ബാഹ്യ ബ്രോക്കറായി അവതരിപ്പിക്കപ്പെടുന്നു, സന്ദേശങ്ങൾക്കായി ഒരു BPMQueue, സിഗ്നലുകൾക്കായി ഒരു BPMTopic വിഷയം (ഇവന്റുകൾ). എല്ലാ സന്ദേശങ്ങളും ഒരൊറ്റ ക്യൂവിലൂടെ കൈമാറുന്നത് ഒരു വിട്ടുവീഴ്ചയാണ്. ബിസിനസ്സ് ലോജിക് തലത്തിൽ, സിസ്റ്റം ഘടനയിൽ മാറ്റങ്ങൾ വരുത്താതെ തന്നെ നിങ്ങൾക്ക് ആവശ്യമുള്ളത്ര പുതിയ തരത്തിലുള്ള സന്ദേശങ്ങൾ ഇപ്പോൾ അവതരിപ്പിക്കാനാകും. ഇതൊരു കാര്യമായ ലളിതവൽക്കരണമാണ്, പക്ഷേ ഇത് ചില അപകടസാധ്യതകൾ വഹിക്കുന്നു, ഇത് ഞങ്ങളുടെ സാധാരണ ജോലികളുടെ പശ്ചാത്തലത്തിൽ, ഞങ്ങൾക്ക് അത്ര പ്രാധാന്യമുള്ളതായി തോന്നുന്നില്ല.

എന്നിരുന്നാലും, ഇവിടെ ഒരു സൂക്ഷ്മതയുണ്ട്: ഓരോ ആപ്ലിക്കേഷനും പ്രവേശന കവാടത്തിലെ ക്യൂവിൽ നിന്ന് അതിന്റെ ഡൊമെയ്‌നിന്റെ പേരിൽ "അതിന്റെ" സന്ദേശങ്ങൾ ഫിൽട്ടർ ചെയ്യുന്നു. കൂടാതെ, സിഗ്നലിന്റെ "സ്കോപ്പ്" ഒരൊറ്റ ആപ്ലിക്കേഷനിലേക്ക് പരിമിതപ്പെടുത്തണമെങ്കിൽ, സിഗ്നലുകളിൽ ഡൊമെയ്ൻ വ്യക്തമാക്കാൻ കഴിയും. ഇത് ബസിന്റെ ബാൻഡ്‌വിഡ്ത്ത് വർദ്ധിപ്പിക്കണം, എന്നാൽ ബിസിനസ് ലോജിക് ഇപ്പോൾ ഡൊമെയ്ൻ നാമങ്ങൾക്കൊപ്പം പ്രവർത്തിക്കണം: സന്ദേശങ്ങൾ അഡ്രസ് ചെയ്യുന്നതിന് നിർബന്ധമാണ്, സിഗ്നലുകൾക്ക് അഭികാമ്യമാണ്.

ഇന്റഗ്രേഷൻ ബസിന്റെ വിശ്വാസ്യത ഉറപ്പാക്കുന്നു

വിശ്വാസ്യത നിരവധി കാര്യങ്ങൾ ഉൾക്കൊള്ളുന്നു:

• തിരഞ്ഞെടുത്ത സന്ദേശ ബ്രോക്കർ വാസ്തുവിദ്യയുടെ ഒരു നിർണായക ഘടകവും പരാജയത്തിന്റെ ഒരു പോയിന്റുമാണ്: അത് മതിയായ തെറ്റ് സഹിഷ്ണുതയുള്ളതായിരിക്കണം. നല്ല പിന്തുണയും ഒരു വലിയ കമ്മ്യൂണിറ്റിയും ഉള്ള സമയം പരിശോധിച്ച നടപ്പിലാക്കലുകൾ മാത്രമേ നിങ്ങൾ ഉപയോഗിക്കാവൂ;
• സന്ദേശ ബ്രോക്കറുടെ ഉയർന്ന ലഭ്യത ഉറപ്പാക്കേണ്ടത് ആവശ്യമാണ്, അതിനായി അത് സംയോജിത ആപ്ലിക്കേഷനുകളിൽ നിന്ന് ശാരീരികമായി വേർതിരിക്കേണ്ടതാണ് (പ്രയോഗിച്ച ബിസിനസ്സ് ലോജിക്കോടുകൂടിയ ആപ്ലിക്കേഷനുകളുടെ ഉയർന്ന ലഭ്യത നൽകുന്നത് വളരെ ബുദ്ധിമുട്ടുള്ളതും ചെലവേറിയതുമാണ്);
• "ഒരിക്കലെങ്കിലും" ഡെലിവറി ഗ്യാരന്റി നൽകാൻ ബ്രോക്കർ ബാധ്യസ്ഥനാണ്. ഇന്റഗ്രേഷൻ ബസിന്റെ വിശ്വസനീയമായ പ്രവർത്തനത്തിന് ഇത് നിർബന്ധിത ആവശ്യകതയാണ്. "കൃത്യമായി ഒരിക്കൽ" ലെവൽ ഗ്യാരണ്ടികൾ ആവശ്യമില്ല: ബിസിനസ്സ് പ്രക്രിയകൾ സാധാരണയായി സന്ദേശങ്ങളുടെയോ ഇവന്റുകളുടെയോ ആവർത്തിച്ചുള്ള വരവിനോട് സംവേദനക്ഷമമല്ല, കൂടാതെ ഇത് പ്രധാനപ്പെട്ട പ്രത്യേക ജോലികളിൽ, ബിസിനസ് ലോജിക്കിലേക്ക് കൂടുതൽ പരിശോധനകൾ ചേർക്കുന്നത് നിരന്തരം ഉപയോഗിക്കുന്നതിനേക്കാൾ എളുപ്പമാണ്. പകരം "ചെലവേറിയ" "ഗ്യാരണ്ടികൾ;
• സന്ദേശങ്ങളും സിഗ്നലുകളും അയയ്‌ക്കുന്നത് ബിസിനസ് പ്രക്രിയകളുടെയും ഡൊമെയ്‌ൻ ഡാറ്റയുടെയും അവസ്ഥയിലെ മാറ്റത്തോടുകൂടിയ ഒരു പൊതു ഇടപാടിൽ ഉൾപ്പെട്ടിരിക്കണം. പാറ്റേൺ ഉപയോഗിക്കുന്നതാണ് ഇഷ്ടപ്പെട്ട ഓപ്ഷൻ ഇടപാട് ഔട്ട്ബോക്സ്, എന്നാൽ ഇതിന് ഡാറ്റാബേസിൽ ഒരു അധിക പട്ടികയും ഒരു റിലേയും ആവശ്യമാണ്. ജെഇഇ ആപ്ലിക്കേഷനുകളിൽ, ഒരു പ്രാദേശിക ജെടിഎ മാനേജർ ഉപയോഗിച്ച് ഇത് ലളിതമാക്കാം, എന്നാൽ തിരഞ്ഞെടുത്ത ബ്രോക്കറുമായുള്ള കണക്ഷന് മോഡിൽ പ്രവർത്തിക്കാൻ കഴിയണം. XA;
• ഇൻകമിംഗ് സന്ദേശങ്ങളും ഇവന്റുകളും കൈകാര്യം ചെയ്യുന്നവർ ബിസിനസ്സ് പ്രക്രിയയുടെ അവസ്ഥ മാറ്റുന്നതിനുള്ള ഇടപാടിനൊപ്പം പ്രവർത്തിക്കണം: അത്തരമൊരു ഇടപാട് പിൻവലിക്കുകയാണെങ്കിൽ, സന്ദേശത്തിന്റെ രസീതും റദ്ദാക്കണം;
• പിശകുകൾ കാരണം കൈമാറാൻ കഴിയാത്ത സന്ദേശങ്ങൾ ഒരു പ്രത്യേക സ്റ്റോറിൽ സൂക്ഷിക്കണം ഡി.എൽ.ക്യു. (ഡെഡ് ലെറ്റർ ക്യൂ). ഇത് ചെയ്യുന്നതിന്, അത്തരം സന്ദേശങ്ങൾ അതിന്റെ സ്റ്റോറേജിൽ സംഭരിക്കുന്ന ഒരു പ്രത്യേക പ്ലാറ്റ്ഫോം മൈക്രോസർവീസ് ഞങ്ങൾ സൃഷ്ടിച്ചു, ആട്രിബ്യൂട്ടുകൾ ഉപയോഗിച്ച് അവയെ സൂചികയിലാക്കുന്നു (ദ്രുത ഗ്രൂപ്പിംഗിനും തിരയലിനും), കൂടാതെ കാണുന്നതിനും ലക്ഷ്യസ്ഥാന വിലാസത്തിലേക്ക് വീണ്ടും അയയ്‌ക്കുന്നതിനും സന്ദേശങ്ങൾ ഇല്ലാതാക്കുന്നതിനും API തുറന്നുകാട്ടുന്നു. സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാർക്ക് അവരുടെ വെബ് ഇന്റർഫേസ് വഴി ഈ സേവനവുമായി പ്രവർത്തിക്കാൻ കഴിയും;
• ബ്രോക്കർ ക്രമീകരണങ്ങളിൽ, സന്ദേശങ്ങൾ DLQ-ലേക്ക് വരാനുള്ള സാധ്യത കുറയ്ക്കുന്നതിന് ഡെലിവറി പുനരവലോകനങ്ങളുടെ എണ്ണവും ഡെലിവറികൾക്കിടയിലുള്ള കാലതാമസവും നിങ്ങൾ ക്രമീകരിക്കേണ്ടതുണ്ട് (ഒപ്റ്റിമൽ പാരാമീറ്ററുകൾ കണക്കാക്കുന്നത് മിക്കവാറും അസാധ്യമാണ്, എന്നാൽ നിങ്ങൾക്ക് അനുഭവപരമായി പ്രവർത്തിക്കാനും അവ ക്രമീകരിക്കാനും കഴിയും. ഓപ്പറേഷൻ);
• DLQ സ്റ്റോർ തുടർച്ചയായി നിരീക്ഷിക്കുകയും മോണിറ്ററിംഗ് സിസ്റ്റം സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാരെ അറിയിക്കുകയും വേണം, അങ്ങനെ സന്ദേശങ്ങൾ ഡെലിവർ ചെയ്യപ്പെടാത്തപ്പോൾ അവർക്ക് കഴിയുന്നത്ര വേഗത്തിൽ പ്രതികരിക്കാൻ കഴിയും. ഇത് ഒരു പരാജയത്തിന്റെ അല്ലെങ്കിൽ ബിസിനസ് ലോജിക് പിശകിന്റെ "നാശ മേഖല" കുറയ്ക്കും;
• ആപ്ലിക്കേഷനുകളുടെ താൽക്കാലിക അഭാവത്തിൽ ഇന്റഗ്രേഷൻ ബസ് ബോധരഹിതമായിരിക്കണം: വിഷയ സബ്‌സ്‌ക്രിപ്‌ഷനുകൾ മോടിയുള്ളതായിരിക്കണം, കൂടാതെ ആപ്ലിക്കേഷന്റെ ഡൊമെയ്‌ൻ നാമം അദ്വിതീയമായിരിക്കണം, അതിനാൽ ആപ്ലിക്കേഷന്റെ അഭാവത്തിൽ മറ്റാരെങ്കിലും അതിന്റെ സന്ദേശം ക്യൂവിൽ നിന്ന് പ്രോസസ്സ് ചെയ്യാൻ ശ്രമിക്കില്ല.

ബിസിനസ് ലോജിക്കിന്റെ ത്രെഡ് സുരക്ഷ ഉറപ്പാക്കുന്നു

ഒരു ബിസിനസ് പ്രക്രിയയുടെ അതേ സന്ദർഭത്തിന് ഒരേസമയം നിരവധി സന്ദേശങ്ങളും ഇവന്റുകളും ലഭിക്കും, അതിന്റെ പ്രോസസ്സിംഗ് സമാന്തരമായി ആരംഭിക്കും. അതേ സമയം, ഒരു ആപ്ലിക്കേഷൻ ഡെവലപ്പർക്ക്, എല്ലാം ലളിതവും ത്രെഡ് സുരക്ഷിതവുമായിരിക്കണം.

ഈ ബിസിനസ്സ് പ്രക്രിയയെ വ്യക്തിഗതമായി ബാധിക്കുന്ന ഓരോ ബാഹ്യ ഇവന്റിനെയും പ്രോസസ്സ് ബിസിനസ് ലോജിക് പ്രോസസ്സ് ചെയ്യുന്നു. ഈ ഇവന്റുകൾ ഇവയാകാം:

• ഒരു ബിസിനസ് പ്രോസസ്സ് ഉദാഹരണം സമാരംഭിക്കുന്നു;
• ഒരു ബിസിനസ് പ്രക്രിയയ്ക്കുള്ളിലെ പ്രവർത്തനവുമായി ബന്ധപ്പെട്ട ഒരു ഉപയോക്തൃ പ്രവർത്തനം;
• ഒരു ബിസിനസ് പ്രോസസ് ഇൻസ്‌റ്റൻസ് സബ്‌സ്‌ക്രൈബ് ചെയ്ത ഒരു സന്ദേശത്തിന്റെയോ സിഗ്നലിന്റെയോ രസീത്;
• ബിസിനസ് പ്രോസസ് ഇൻസ്‌റ്റൻസ് പ്രകാരം സജ്ജീകരിച്ച ടൈമറിന്റെ കാലഹരണപ്പെടൽ;
• API വഴിയുള്ള നിയന്ത്രണ പ്രവർത്തനം (ഉദാ. പ്രോസസ് അബോർട്ട്).

അത്തരം ഓരോ ഇവന്റിനും ഒരു ബിസിനസ്സ് പ്രക്രിയയുടെ അവസ്ഥ മാറ്റാൻ കഴിയും: ചില പ്രവർത്തനങ്ങൾ അവസാനിക്കാം, മറ്റുള്ളവ ആരംഭിക്കാം, സ്ഥിരമായ പ്രോപ്പർട്ടികളുടെ മൂല്യങ്ങൾ മാറാം. ഏതെങ്കിലും പ്രവർത്തനം അവസാനിപ്പിക്കുന്നത് ഇനിപ്പറയുന്ന ഒന്നോ അതിലധികമോ പ്രവർത്തനങ്ങളുടെ സജീവമാക്കലിന് കാരണമായേക്കാം. അവർക്ക് മറ്റ് ഇവന്റുകൾക്കായുള്ള കാത്തിരിപ്പ് അവസാനിപ്പിക്കാം, അല്ലെങ്കിൽ അവർക്ക് അധിക ഡാറ്റയൊന്നും ആവശ്യമില്ലെങ്കിൽ, അതേ ഇടപാടിൽ അവർക്ക് പൂർത്തിയാക്കാനാകും. ഇടപാട് അവസാനിപ്പിക്കുന്നതിന് മുമ്പ്, ബിസിനസ്സ് പ്രക്രിയയുടെ പുതിയ അവസ്ഥ ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്നു, അവിടെ അത് അടുത്ത ബാഹ്യ ഇവന്റിനായി കാത്തിരിക്കും.

റിലേഷണൽ ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്ന പെർസിസ്റ്റന്റ് ബിസിനസ് പ്രോസസ് ഡാറ്റ, അപ്‌ഡേറ്റിനായി തിരഞ്ഞെടുക്കുക ഉപയോഗിക്കുമ്പോൾ വളരെ സൗകര്യപ്രദമായ പ്രോസസ്സിംഗ് സിൻക്രൊണൈസേഷൻ പോയിന്റാണ്. ഒരു ഇടപാടിന് ഡാറ്റാബേസിൽ നിന്ന് ബിസിനസ് പ്രക്രിയയുടെ അവസ്ഥ മാറ്റാൻ കഴിഞ്ഞാൽ, സമാന്തരമായി മറ്റൊരു ഇടപാടിനും അതേ അവസ്ഥ മറ്റൊരു മാറ്റത്തിന് ലഭിക്കില്ല, ആദ്യ ഇടപാട് പൂർത്തിയായതിന് ശേഷം രണ്ടാമത്തേത് ഇതിനകം മാറിയ അവസ്ഥ ലഭിക്കുമെന്ന് ഉറപ്പുനൽകുന്നു.

DBMS വശത്തുള്ള അശുഭാപ്തി ലോക്കുകൾ ഉപയോഗിച്ച്, ആവശ്യമായ എല്ലാ ആവശ്യങ്ങളും ഞങ്ങൾ നിറവേറ്റുന്നു എസിഐഡി, കൂടാതെ റണ്ണിംഗ് ഇൻസ്‌റ്റൻസുകളുടെ എണ്ണം വർദ്ധിപ്പിച്ച് ബിസിനസ്സ് ലോജിക്ക് ഉപയോഗിച്ച് ആപ്ലിക്കേഷൻ സ്കെയിൽ ചെയ്യാനുള്ള കഴിവ് നിലനിർത്തുക.

എന്നിരുന്നാലും, അശുഭാപ്തി പൂട്ടുകൾ നമ്മെ തടസ്സപ്പെടുത്തുന്നു, അതിനർത്ഥം ബിസിനസ്സ് ലോജിക്കിലെ ചില മോശം കേസുകളിൽ ഡെഡ്‌ലോക്കുകൾ ഉണ്ടാകുമ്പോൾ, അപ്‌ഡേറ്റിനായി തിരഞ്ഞെടുക്കുക എന്നത് ഇപ്പോഴും ന്യായമായ ചില സമയപരിധിയിലേക്ക് പരിമിതപ്പെടുത്തണം എന്നാണ്.

മറ്റൊരു പ്രശ്നം ബിസിനസ്സ് പ്രക്രിയയുടെ തുടക്കത്തിന്റെ സമന്വയമാണ്. ബിസിനസ്സ് പ്രോസസ്സ് ഉദാഹരണം ഇല്ലെങ്കിലും, ഡാറ്റാബേസിൽ ഒരു അവസ്ഥയും ഇല്ല, അതിനാൽ വിവരിച്ച രീതി പ്രവർത്തിക്കില്ല. ഒരു പ്രത്യേക സ്കോപ്പിൽ ഒരു ബിസിനസ് പ്രോസസ് ഇൻസ്‌റ്റൻസിന്റെ പ്രത്യേകത ഉറപ്പാക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, നിങ്ങൾക്ക് പ്രോസസ്സ് ക്ലാസും അനുബന്ധ സ്കോപ്പുമായി ബന്ധപ്പെട്ട ഒരുതരം സിൻക്രൊണൈസേഷൻ ഒബ്‌ജക്റ്റ് ആവശ്യമാണ്. ഈ പ്രശ്നം പരിഹരിക്കാൻ, ഒരു ബാഹ്യ സേവനത്തിലൂടെ URI ഫോർമാറ്റിലുള്ള ഒരു കീ വ്യക്തമാക്കിയ അനിയന്ത്രിതമായ ഉറവിടത്തിൽ ഒരു ലോക്ക് എടുക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്ന മറ്റൊരു ലോക്കിംഗ് സംവിധാനം ഞങ്ങൾ ഉപയോഗിക്കുന്നു.

ഞങ്ങളുടെ ഉദാഹരണങ്ങളിൽ, InitialPlayer ബിസിനസ്സ് പ്രക്രിയയിൽ ഒരു പ്രഖ്യാപനം അടങ്ങിയിരിക്കുന്നു

uniqueConstraint = UniqueConstraints.singleton

അതിനാൽ, അനുബന്ധ കീയുടെ ലോക്ക് എടുക്കുന്നതും റിലീസ് ചെയ്യുന്നതും സംബന്ധിച്ച സന്ദേശങ്ങൾ ലോഗിൽ അടങ്ങിയിരിക്കുന്നു. മറ്റ് ബിസിനസ്സ് പ്രക്രിയകൾക്കായി അത്തരം സന്ദേശങ്ങളൊന്നുമില്ല: യുണീക് കൺസ്ട്രൈന്റ് സജ്ജീകരിച്ചിട്ടില്ല.

സ്ഥിരമായ അവസ്ഥയിൽ ബിസിനസ് പ്രക്രിയ പ്രശ്നങ്ങൾ

ചിലപ്പോൾ ഒരു സ്ഥിരമായ അവസ്ഥ ഉണ്ടാകുന്നത് സഹായിക്കുക മാത്രമല്ല, വികസനത്തെ ശരിക്കും തടസ്സപ്പെടുത്തുകയും ചെയ്യുന്നു.
ബിസിനസ് ലോജിക്കിലും കൂടാതെ / അല്ലെങ്കിൽ ബിസിനസ് പ്രോസസ് മോഡലിലും നിങ്ങൾക്ക് മാറ്റങ്ങൾ വരുത്തേണ്ടി വരുമ്പോൾ പ്രശ്നങ്ങൾ ആരംഭിക്കുന്നു. അത്തരം മാറ്റങ്ങളൊന്നും ബിസിനസ് പ്രക്രിയകളുടെ പഴയ അവസ്ഥയുമായി പൊരുത്തപ്പെടുന്നതായി കണ്ടെത്തിയില്ല. ഡാറ്റാബേസിൽ നിരവധി "തത്സമയ" സംഭവങ്ങൾ ഉണ്ടെങ്കിൽ, പൊരുത്തമില്ലാത്ത മാറ്റങ്ങൾ വരുത്തുന്നത് വളരെയധികം പ്രശ്‌നങ്ങൾക്ക് കാരണമാകും, ഇത് jBPM ഉപയോഗിക്കുമ്പോൾ ഞങ്ങൾ പലപ്പോഴും അഭിമുഖീകരിക്കുന്നു.

മാറ്റത്തിന്റെ ആഴം അനുസരിച്ച്, നിങ്ങൾക്ക് രണ്ട് തരത്തിൽ പ്രവർത്തിക്കാൻ കഴിയും:

1. പഴയതിലേക്ക് പൊരുത്തപ്പെടാത്ത മാറ്റങ്ങൾ വരുത്താതിരിക്കാൻ ഒരു പുതിയ ബിസിനസ് പ്രോസസ്സ് തരം സൃഷ്ടിക്കുക, പുതിയ സംഭവങ്ങൾ ആരംഭിക്കുമ്പോൾ പഴയതിന് പകരം അത് ഉപയോഗിക്കുക. പഴയ സംഭവങ്ങൾ "പഴയ രീതിയിൽ" പ്രവർത്തിക്കുന്നത് തുടരും;
2. ബിസിനസ് ലോജിക് അപ്‌ഡേറ്റ് ചെയ്യുമ്പോൾ ബിസിനസ് പ്രക്രിയകളുടെ സ്ഥിരമായ അവസ്ഥ മൈഗ്രേറ്റ് ചെയ്യുക.

ആദ്യ വഴി ലളിതമാണ്, പക്ഷേ അതിന്റെ പരിമിതികളും ദോഷങ്ങളുമുണ്ട്, ഉദാഹരണത്തിന്:

• പല ബിസിനസ് പ്രോസസ് മോഡലുകളിലും ബിസിനസ് ലോജിക്കിന്റെ തനിപ്പകർപ്പ്, ബിസിനസ് ലോജിക്കിന്റെ അളവിൽ വർദ്ധനവ്;
• പലപ്പോഴും ഒരു പുതിയ ബിസിനസ്സ് ലോജിക്കിലേക്കുള്ള ഒരു തൽക്ഷണ പരിവർത്തനം ആവശ്യമാണ് (ഏതാണ്ട് എപ്പോഴും സംയോജന ചുമതലകളുടെ കാര്യത്തിൽ);
• കാലഹരണപ്പെട്ട മോഡലുകൾ ഇല്ലാതാക്കാൻ ഏത് ഘട്ടത്തിലാണ് സാധ്യമാകുന്നതെന്ന് ഡവലപ്പർക്ക് അറിയില്ല.

പ്രായോഗികമായി, ഞങ്ങൾ രണ്ട് സമീപനങ്ങളും ഉപയോഗിക്കുന്നു, പക്ഷേ ഞങ്ങളുടെ ജീവിതം ലളിതമാക്കാൻ നിരവധി തീരുമാനങ്ങൾ എടുത്തിട്ടുണ്ട്:

• ഡാറ്റാബേസിൽ, ബിസിനസ് പ്രക്രിയയുടെ സ്ഥിരമായ അവസ്ഥ എളുപ്പത്തിൽ വായിക്കാവുന്നതും എളുപ്പത്തിൽ പ്രോസസ്സ് ചെയ്യപ്പെടുന്നതുമായ രൂപത്തിൽ സംഭരിച്ചിരിക്കുന്നു: JSON ഫോർമാറ്റ് സ്ട്രിംഗിൽ. ആപ്ലിക്കേഷന്റെ അകത്തും പുറത്തും മൈഗ്രേഷനുകൾ നടത്താൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. അങ്ങേയറ്റത്തെ സന്ദർഭങ്ങളിൽ, നിങ്ങൾക്ക് ഇത് ഹാൻഡിലുകൾ ഉപയോഗിച്ച് മാറ്റാനും കഴിയും (ഡീബഗ്ഗിംഗ് സമയത്ത് വികസനത്തിൽ പ്രത്യേകിച്ചും ഉപയോഗപ്രദമാണ്);
• ഇന്റഗ്രേഷൻ ബിസിനസ്സ് ലോജിക് ബിസിനസ്സ് പ്രക്രിയകളുടെ പേരുകൾ ഉപയോഗിക്കുന്നില്ല, അതിനാൽ എപ്പോൾ വേണമെങ്കിലും പങ്കെടുക്കുന്ന പ്രക്രിയകളിലൊന്ന് പുതിയൊരു പേര് ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കാൻ കഴിയും (ഉദാഹരണത്തിന്, "InitialPlayerV2"). സന്ദേശങ്ങളുടെയും സിഗ്നലുകളുടെയും പേരുകളിലൂടെയാണ് ബൈൻഡിംഗ് സംഭവിക്കുന്നത്;
• പ്രോസസ്സ് മോഡലിന് ഒരു പതിപ്പ് നമ്പർ ഉണ്ട്, ഈ മോഡലിൽ പൊരുത്തമില്ലാത്ത മാറ്റങ്ങൾ വരുത്തിയാൽ ഞങ്ങൾ അത് വർദ്ധിപ്പിക്കും, കൂടാതെ ഈ നമ്പർ പ്രോസസ്സിന്റെ അവസ്ഥയ്‌ക്കൊപ്പം സംഭരിക്കുകയും ചെയ്യും;
• മോഡലിന്റെ പതിപ്പ് നമ്പർ മാറിയിട്ടുണ്ടെങ്കിൽ മൈഗ്രേഷൻ നടപടിക്രമം പ്രവർത്തിക്കാൻ കഴിയുന്ന ഒരു സൗകര്യപ്രദമായ ഒബ്‌ജക്റ്റ് മോഡലിലേക്ക് പ്രോസസ്സിന്റെ സ്ഥിരമായ അവസ്ഥ ആദ്യം അടിസ്ഥാനത്തിൽ നിന്ന് വായിക്കുന്നു;
• മൈഗ്രേഷൻ നടപടിക്രമം ബിസിനസ്സ് ലോജിക്കിന് അടുത്തായി സ്ഥാപിക്കുകയും ഡാറ്റാബേസിൽ നിന്ന് പുനഃസ്ഥാപിക്കുന്ന സമയത്ത് ബിസിനസ്സ് പ്രക്രിയയുടെ ഓരോ സംഭവത്തിനും "അലസ" എന്ന് വിളിക്കുകയും ചെയ്യുന്നു;
• നിങ്ങൾക്ക് എല്ലാ പ്രോസസ്സ് സംഭവങ്ങളുടെയും അവസ്ഥ വേഗത്തിലും സമന്വയമായും മൈഗ്രേറ്റ് ചെയ്യണമെങ്കിൽ, കൂടുതൽ ക്ലാസിക് ഡാറ്റാബേസ് മൈഗ്രേഷൻ സൊല്യൂഷനുകൾ ഉപയോഗിക്കും, പക്ഷേ നിങ്ങൾ അവിടെ JSON-മായി പ്രവർത്തിക്കേണ്ടതുണ്ട്.

ബിസിനസ് പ്രക്രിയകൾക്കായി എനിക്ക് മറ്റൊരു ചട്ടക്കൂട് ആവശ്യമുണ്ടോ?

ലേഖനത്തിൽ വിവരിച്ചിരിക്കുന്ന പരിഹാരങ്ങൾ ഞങ്ങളുടെ ജീവിതത്തെ ഗണ്യമായി ലഘൂകരിക്കാനും ആപ്ലിക്കേഷൻ ഡെവലപ്‌മെന്റ് തലത്തിൽ പരിഹരിച്ച പ്രശ്‌നങ്ങളുടെ പരിധി വിപുലീകരിക്കാനും ബിസിനസ് ലോജിക് മൈക്രോസർവീസുകളായി വേർതിരിക്കുന്ന ആശയം കൂടുതൽ ആകർഷകമാക്കാനും ഞങ്ങളെ അനുവദിച്ചു. ഇതിനായി, ധാരാളം ജോലികൾ ചെയ്തു, ബിസിനസ്സ് പ്രക്രിയകൾക്കായി വളരെ “കനംകുറഞ്ഞ” ചട്ടക്കൂട് സൃഷ്ടിച്ചു, അതുപോലെ തന്നെ വിശാലമായ പ്രയോഗിച്ച ജോലികളുടെ പശ്ചാത്തലത്തിൽ തിരിച്ചറിഞ്ഞ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള സേവന ഘടകങ്ങളും. ഈ ഫലങ്ങൾ പങ്കിടാനും പൊതുവായ ഘടകങ്ങളുടെ വികസനം ഒരു സ്വതന്ത്ര ലൈസൻസിന് കീഴിൽ ഓപ്പൺ ആക്‌സസിലേക്ക് കൊണ്ടുവരാനും ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഇതിന് കുറച്ച് പരിശ്രമവും സമയവും വേണ്ടിവരും. അത്തരം പരിഹാരങ്ങളുടെ ആവശ്യം മനസ്സിലാക്കുന്നത് ഞങ്ങൾക്ക് ഒരു അധിക പ്രോത്സാഹനമായിരിക്കും. നിർദ്ദിഷ്ട ലേഖനത്തിൽ, ചട്ടക്കൂടിന്റെ കഴിവുകളിൽ വളരെ കുറച്ച് ശ്രദ്ധ മാത്രമേ നൽകുന്നുള്ളൂ, എന്നാൽ അവയിൽ ചിലത് അവതരിപ്പിച്ച ഉദാഹരണങ്ങളിൽ നിന്ന് ദൃശ്യമാണ്. എന്നിരുന്നാലും ഞങ്ങൾ ഞങ്ങളുടെ ചട്ടക്കൂട് പ്രസിദ്ധീകരിക്കുകയാണെങ്കിൽ, ഒരു പ്രത്യേക ലേഖനം അതിനായി നീക്കിവയ്ക്കും. അതിനിടയിൽ, ചോദ്യത്തിന് ഉത്തരം നൽകിക്കൊണ്ട് നിങ്ങൾ ഒരു ചെറിയ ഫീഡ്‌ബാക്ക് നൽകിയാൽ ഞങ്ങൾ നന്ദിയുള്ളവരായിരിക്കും:

രജിസ്റ്റർ ചെയ്ത ഉപയോക്താക്കൾക്ക് മാത്രമേ സർവേയിൽ പങ്കെടുക്കാൻ കഴിയൂ. സൈൻ ഇൻദയവായി.

ബിസിനസ് പ്രക്രിയകൾക്കായി എനിക്ക് മറ്റൊരു ചട്ടക്കൂട് ആവശ്യമുണ്ടോ?

• 18,8%അതെ, ഞാൻ വളരെക്കാലമായി ഇതുപോലൊന്ന് അന്വേഷിക്കുന്നു.

• 12,5%നിങ്ങളുടെ നടപ്പാക്കലിനെക്കുറിച്ച് കൂടുതലറിയുന്നത് രസകരമാണ്, ഇത് ഉപയോഗപ്രദമായേക്കാം2

• 6,2%ഞങ്ങൾ നിലവിലുള്ള ചട്ടക്കൂടുകളിലൊന്ന് ഉപയോഗിക്കുന്നു, പക്ഷേ അത് മാറ്റിസ്ഥാപിക്കുന്നതിനെക്കുറിച്ച് ഞങ്ങൾ ചിന്തിക്കുന്നു1

• 18,8%ഞങ്ങൾ നിലവിലുള്ള ചട്ടക്കൂടുകളിലൊന്ന് ഉപയോഗിക്കുന്നു, എല്ലാം യോജിക്കുന്നു3

• 18,8%ചട്ടക്കൂടില്ലാതെ നേരിടൽ3

• 25,0%സ്വന്തമായി എഴുതുക4

16 ഉപയോക്താക്കൾ വോട്ട് ചെയ്തു. 7 ഉപയോക്താക്കൾ വിട്ടുനിന്നു.

അവലംബം: www.habr.com