Na žalost ta izraz nima dobre analogije v ruskem jeziku. Wikipedia daje "večnajemništvo, večnajemništvo." To se včasih imenuje "večkratno lastništvo". Ti izrazi so lahko nekoliko zmedeni, saj zadeva ni sama po sebi povezana niti z najemom niti z lastništvom. To je vprašanje arhitekture programske opreme in organizacije njenega delovanja. In slednje ni nič manj pomembno.
Razumevanje večnajemništva smo začeli oblikovati hkrati z oblikovanjem pristopa k oblačnemu (storitvenemu) modelu dela v 1C:Podjetju. To je bilo pred nekaj leti. In od takrat se je naše razumevanje nenehno širilo. Nenehno odkrivamo vedno več novih vidikov te teme (prednosti, slabosti, težave, značilnosti itd.).
Včasih razvijalci razumejo večnajemništvo kot zelo preprosto temo: "da bi bili podatki več organizacij shranjeni v eni bazi podatkov, morate v vse tabele dodati stolpec z identifikatorjem organizacije in na njem nastaviti filter." Od tega trenutka smo seveda tudi začeli s preučevanjem problematike. A so hitro ugotovili, da je to le ena jasa (tudi, mimogrede, ne lahka). Na splošno je to "cela država".
Osnovno idejo večnajemništva lahko opišemo nekako takole. Tipična uporaba je koča, zasnovana za namestitev ene družine, ki uporablja svojo infrastrukturo (stene, streha, oskrba z vodo, ogrevanje itd.). Večnajemniška prijava je stanovanjska hiša. V njem vsaka družina uporablja enako infrastrukturo, sama infrastruktura pa je izvedena za celotno hišo.
Ali je večnajemniški pristop dober ali slab? O tem lahko najdete zelo različna mnenja. Zdi se, da sploh ni "dobrega ali slabega". Primerjati morate prednosti in slabosti v kontekstu konkretnih nalog, ki jih rešujete. Ampak to je posebna tema...
V najpreprostejšem smislu je cilj večnajemništva zmanjšati stroške vzdrževanja aplikacije s »socializacijo« stroškov infrastrukture. To je enako gibanje kot zmanjšanje stroškov aplikacije z uporabo produkcijske rešitve (po možnosti s prilagajanjem in spreminjanjem), namesto da bi jo napisali »po naročilu«. Samo v enem primeru je razvoj socializiran, v drugem pa izkoriščanje.
Še več, ponavljamo, neposredne povezave z načinom prodaje ni. Večnajemniško arhitekturo je mogoče uporabiti tudi v IT infrastrukturi podjetja ali oddelka za avtomatizacijo velikega števila podobnih podružnic in holdingov.
Lahko rečemo, da večnajemništvo ni le stvar organizacije shranjevanja podatkov. To je model delovanja aplikacije kot celote (vključno s pomembnim delom njene arhitekture, modelom uvajanja in organizacijo vzdrževanja).
Najtežja in najbolj zanimiva stvar pri večnajemniškem modelu se nam zdi, da se bistvo aplikacije »razcepi«. Del funkcionalnosti deluje z določenimi podatkovnimi območji (stanovanji) in jih »ne zanima« dejstvo, da so stanovalci v drugih stanovanjih. In nekateri dojemajo hišo kot celoto in delajo za vse prebivalce hkrati. Ob tem pa slednje ne morejo mimo dejstva, da gre vendarle za ločena stanovanja in je treba zagotoviti potrebno stopnjo razdrobljenosti in varnosti.
V 1C:Enterprise je večnajemniški model implementiran na ravni več tehnologij. To so mehanizmi platforme 1C:Enterprise, mehanizmi"In"«, mehanizmi (knjižnice standardnih podsistemov).
Vsak od teh elementov prispeva k izgradnji celotne infrastrukture stanovanjske stavbe. Zakaj je to implementirano v več tehnologijah in ne v eni, na primer v platformi? Prvič, ker je po našem mnenju nekatere mehanizme povsem primerno spremeniti za določeno možnost uvajanja. Toda na splošno je to težko vprašanje in nenehno se soočamo z izbiro - na kateri ravni je bolje izvajati ta ali oni vidik večnajemništva.
Očitno je bilo treba osnovni del mehanizmov implementirati v platformo. No, na primer, dejansko ločevanje podatkov. Tu se običajno začne govoriti o večnajemništvu. Toda na koncu je večnajemniški model »prepotoval« pomemben del mehanizmov platforme in zahteval njihovo dodelavo, v nekaterih primerih pa tudi premislek.
Na ravni platforme smo implementirali točno osnovne mehanizme. Omogočajo ustvarjanje aplikacij, ki delujejo v večnajemniškem modelu. Da pa bodo aplikacije "živele in delale" v takem modelu, morate imeti sistem za upravljanje njihovih "življenjskih dejavnosti". Za to so zaslužne tehnologije 1cFresh in enotna plast poslovne logike na ravni BSP. Tako kot v večstanovanjski stavbi infrastruktura nudi stanovalcem vse, kar potrebujejo, tako 1cFresh tehnologije zagotavljajo vse, kar potrebujejo za aplikacije, ki delujejo v večnajemniškem modelu. In da lahko aplikacije komunicirajo s to infrastrukturo (brez bistvenih sprememb), so v njih nameščeni ustrezni "konektorji" v obliki podsistemov BSP.
Z vidika mehanizmov platforme je lahko opaziti, da ko pridobivamo izkušnje in razvijamo primer uporabe v oblaku "1C:Enterprise", širimo sestavo mehanizmov, ki so vključeni v to arhitekturo. Dajmo en primer. V večnajemniškem modelu se vloge udeležencev aplikacijskih storitev bistveno spremenijo. Vloga (stopnja odgovornosti) odgovornih za delovanje aplikacij se bistveno poveča. Postalo je potrebno, da imajo močnejša orodja za nadzor aplikacij. Ker uporabniki aplikacije (rezidenti) zaupajo predvsem ponudniku, s katerim sodelujejo. Da bi to naredili, smo implementirali novo . Ta mehanizem omogoča skrbnikom ponudnika, da omejijo svobodo razvijalcev aplikacij na zahtevano raven varnosti – v bistvu, da izolirajo delovanje aplikacije za vsakega najemnika znotraj določenega peskovnika.
Nič manj zanimiva ni arhitektura za upravljanje aplikacij, ki delujejo v večnajemniškem načinu (kar je implementirano v tehnologijah 1cFresh in BSP). Tu so v primerjavi s konvencionalnim modelom uvedbe zahteve po avtomatizaciji procesov upravljanja znatno povečane. Obstaja na desetine takšnih procesov: ustvarjanje novih podatkovnih območij (»stanovanj«), posodabljanje aplikacij, posodabljanje regulativnih informacij, varnostne kopije itd. In seveda se povečujejo zahteve glede stopnje zanesljivosti in razpoložljivosti. Na primer, da bi zagotovili zanesljivo interakcijo med aplikacijami in komponentami nadzornega sistema, smo uvedli tehnologijo asinhronega klicnega sistema z zagotovljeno dostavo.
Zelo subtilna točka je način socializacije podatkov in procesov. Enostavno se zdi (če se komu zdi) samo na prvi pogled. Največji izziv je ravnotežje med centralizacijo podatkov in procesov ter decentralizacijo. Po eni strani vam centralizacija omogoča zmanjšanje stroškov (prostor na disku, procesorski viri, skrbniški napor ...). Po drugi strani pa omejuje svobodo »najemnikov«. To je ravno eden od trenutkov "razcepitve" aplikacije, ko mora razvijalec hkrati razmišljati o aplikaciji v ožjem smislu (služi enemu "stanovanju") in v širšem smislu (služi vsem "najemnikom" hkrati). .
Kot primer takšne "dileme" lahko navedemo regulativne in referenčne informacije. Seveda obstaja velika skušnjava, da bi bila skupna vsem "najemnikom" hiše. To vam omogoča, da ga shranite v enem izvodu in ga posodobite za vse hkrati. A zgodi se, da nekateri prebivalci potrebujejo posebne spremembe. Nenavadno je, da se to v praksi dogaja, tudi za informacije, ki jih določijo regulatorji (vladni organi). To se izkaže za težko vprašanje: družiti se ali ne? Seveda je mamljivo, da bi bile informacije splošne za vse in zasebne za tiste, ki to želijo. In to že vodi v zelo težko izvedbo. Ampak delamo na tem ...
Drugi primer je zasnova izvajanja rednih procesov (izvajajo se po urniku, sproži nadzorni sistem itd.). Po eni strani jih je mogoče implementirati za vsako podatkovno področje posebej. To je lažje in bolj priročno. Toda po drugi strani tako fina zrnatost povzroča veliko obremenitev sistema. Če želite zmanjšati obremenitev, morate uvesti socializirane procese. Vendar zahtevajo natančnejšo študijo.
Seveda se ob tem odpira zelo pomembno vprašanje. Kako lahko razvijalci aplikacij zagotovijo večnajemništvo? Kaj morajo storiti za to? Seveda pa stremimo k temu, da breme tehnološke in infrastrukturne problematike v največji možni meri pade na pleča dobavljene tehnologije, razvijalec aplikacije pa razmišlja le v okviru nalog poslovne logike. Toda tako kot pri drugih pomembnih arhitekturnih vprašanjih morajo razvijalci aplikacij imeti nekaj razumevanja dela v večnajemniškem modelu in pri razvoju aplikacij bo potrebno nekaj truda. Zakaj? Ker obstajajo točke, ki jih tehnologija ne more zagotoviti samodejno, ne da bi upoštevala semantiko podatkov. Na primer, enaka opredelitev meja informacijske socializacije. Vendar se trudimo, da bi bile te težave majhne. Primeri implementacije takih aplikacij že obstajajo.
Pomembna točka v kontekstu implementacije večnajemništva v 1C:Enterprise je, da ustvarjamo hibridni model, v katerem lahko ena aplikacija deluje tako v večnajemniškem kot običajnem načinu. To je zelo težka naloga in predmet posebne razprave.
Vir: www.habr.com