ದುರದೃಷ್ಟವಶಾತ್, ಈ ಪದವು ಉತ್ತಮ ರಷ್ಯನ್ ಭಾಷೆಯ ಅನಲಾಗ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ. ವಿಕಿಪೀಡಿಯಾ ನೀಡುತ್ತದೆ "ಬಹು-ಹಿಡುವಳಿ, ಬಹು ಹಿಡುವಳಿ." ಇದನ್ನು ಕೆಲವೊಮ್ಮೆ "ಬಹು ಮಾಲೀಕತ್ವ" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಈ ನಿಯಮಗಳು ಸ್ವಲ್ಪ ಗೊಂದಲಮಯವಾಗಿರಬಹುದು, ಏಕೆಂದರೆ ವಿಷಯವು ಸ್ವಾಭಾವಿಕವಾಗಿ ಬಾಡಿಗೆಗೆ ಅಥವಾ ಮಾಲೀಕತ್ವದೊಂದಿಗೆ ಸಂಬಂಧ ಹೊಂದಿಲ್ಲ. ಇದು ಸಾಫ್ಟ್ವೇರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಅದರ ಕಾರ್ಯಾಚರಣೆಯ ಸಂಘಟನೆಯ ಪ್ರಶ್ನೆಯಾಗಿದೆ. ಮತ್ತು ಎರಡನೆಯದು ಕಡಿಮೆ ಮುಖ್ಯವಲ್ಲ.
ನಾವು 1C: ಎಂಟರ್ಪ್ರೈಸ್ನಲ್ಲಿ ಕ್ಲೌಡ್ (ಸೇವೆ) ಮಾದರಿಯ ಕೆಲಸದ ವಿಧಾನವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಿದ ಅದೇ ಸಮಯದಲ್ಲಿ ನಾವು ಮಲ್ಟಿಟೆನೆನ್ಸಿಯ ಬಗ್ಗೆ ನಮ್ಮ ತಿಳುವಳಿಕೆಯನ್ನು ರೂಪಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಇದು ಹಲವಾರು ವರ್ಷಗಳ ಹಿಂದೆ. ಮತ್ತು ಅಂದಿನಿಂದ ನಮ್ಮ ತಿಳುವಳಿಕೆ ನಿರಂತರವಾಗಿ ವಿಸ್ತರಿಸಿದೆ. ಈ ವಿಷಯದ (ಸಾಧಕ, ಬಾಧಕ, ತೊಂದರೆಗಳು, ವೈಶಿಷ್ಟ್ಯಗಳು, ಇತ್ಯಾದಿ) ಹೆಚ್ಚು ಹೆಚ್ಚು ಹೊಸ ಅಂಶಗಳನ್ನು ನಾವು ನಿರಂತರವಾಗಿ ಕಂಡುಹಿಡಿಯುತ್ತಿದ್ದೇವೆ.
ಕೆಲವೊಮ್ಮೆ ಡೆವಲಪರ್ಗಳು ಬಹುತ್ವವನ್ನು ಸರಳ ವಿಷಯವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ: "ಹಲವಾರು ಸಂಸ್ಥೆಗಳ ಡೇಟಾವನ್ನು ಒಂದು ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು, ನೀವು ಎಲ್ಲಾ ಕೋಷ್ಟಕಗಳಿಗೆ ಸಂಸ್ಥೆಯ ಗುರುತಿಸುವಿಕೆಯೊಂದಿಗೆ ಕಾಲಮ್ ಅನ್ನು ಸೇರಿಸಬೇಕು ಮತ್ತು ಅದರ ಮೇಲೆ ಫಿಲ್ಟರ್ ಅನ್ನು ಹೊಂದಿಸಬೇಕು." ನಾವು, ಸಹಜವಾಗಿ, ಈ ಕ್ಷಣದಿಂದ ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ನಮ್ಮ ಅಧ್ಯಯನವನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಆದರೆ ಇದು ಕೇವಲ ಒಂದು ತೆರವುಗೊಳಿಸುವಿಕೆ ಎಂದು ಅವರು ಶೀಘ್ರವಾಗಿ ಅರಿತುಕೊಂಡರು (ಸಹ, ಮೂಲಕ, ಸುಲಭವಲ್ಲ). ಸಾಮಾನ್ಯವಾಗಿ, ಇದು "ಇಡೀ ದೇಶ".
ಬಹುತ್ವದ ಮೂಲ ಕಲ್ಪನೆಯನ್ನು ಈ ರೀತಿ ವಿವರಿಸಬಹುದು. ಒಂದು ವಿಶಿಷ್ಟವಾದ ಅಪ್ಲಿಕೇಶನ್ ಒಂದು ಕುಟುಂಬಕ್ಕೆ ಸರಿಹೊಂದಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಕಾಟೇಜ್ ಆಗಿದೆ, ಇದು ಅದರ ಮೂಲಸೌಕರ್ಯವನ್ನು (ಗೋಡೆಗಳು, ಛಾವಣಿ, ನೀರು ಸರಬರಾಜು, ತಾಪನ, ಇತ್ಯಾದಿ) ಬಳಸುತ್ತದೆ. ಮಲ್ಟಿಟೆನೆನ್ಸಿ ಅಪ್ಲಿಕೇಶನ್ ಒಂದು ಅಪಾರ್ಟ್ಮೆಂಟ್ ಕಟ್ಟಡವಾಗಿದೆ. ಅದರಲ್ಲಿ, ಪ್ರತಿ ಕುಟುಂಬವು ಒಂದೇ ಮೂಲಸೌಕರ್ಯವನ್ನು ಬಳಸುತ್ತದೆ, ಆದರೆ ಮೂಲಸೌಕರ್ಯವನ್ನು ಇಡೀ ಮನೆಗೆ ಅಳವಡಿಸಲಾಗಿದೆ.
ಮಲ್ಟಿಟೆನೆನ್ಸಿ ವಿಧಾನವು ಒಳ್ಳೆಯದು ಅಥವಾ ಕೆಟ್ಟದ್ದೇ? ಇದರ ಬಗ್ಗೆ ನೀವು ವಿಭಿನ್ನ ಅಭಿಪ್ರಾಯಗಳನ್ನು ಕಾಣಬಹುದು. ಯಾವುದೇ "ಒಳ್ಳೆಯದು ಅಥವಾ ಕೆಟ್ಟದು" ಇಲ್ಲ ಎಂದು ತೋರುತ್ತದೆ. ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಗಳನ್ನು ಪರಿಹರಿಸುವ ಸಂದರ್ಭದಲ್ಲಿ ನೀವು ಸಾಧಕ-ಬಾಧಕಗಳನ್ನು ಹೋಲಿಸಬೇಕು. ಆದರೆ ಇದು ಪ್ರತ್ಯೇಕ ವಿಷಯವಾಗಿದೆ ...
ಅದರ ಸರಳ ಅರ್ಥದಲ್ಲಿ, ಮೂಲಸೌಕರ್ಯ ವೆಚ್ಚಗಳನ್ನು "ಸಾಮಾಜಿಕಗೊಳಿಸುವ" ಮೂಲಕ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಮಲ್ಟಿಟೆನೆನ್ಸಿಯ ಗುರಿಯಾಗಿದೆ. ಇದು "ಆರ್ಡರ್ ಮಾಡಲು" ಬರೆಯುವ ಬದಲು ಉತ್ಪಾದನಾ ಪರಿಹಾರವನ್ನು (ಬಹುಶಃ ಗ್ರಾಹಕೀಕರಣ ಮತ್ತು ಮಾರ್ಪಾಡುಗಳೊಂದಿಗೆ) ಬಳಸಿಕೊಂಡು ಅಪ್ಲಿಕೇಶನ್ನ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಅದೇ ಚಲನೆಯಾಗಿದೆ. ಒಂದು ಸಂದರ್ಭದಲ್ಲಿ ಮಾತ್ರ ಅಭಿವೃದ್ಧಿ ಸಾಮಾಜಿಕವಾಗಿದೆ, ಮತ್ತು ಇನ್ನೊಂದರಲ್ಲಿ - ಶೋಷಣೆ.
ಇದಲ್ಲದೆ, ನಾವು ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ, ಮಾರಾಟದ ವಿಧಾನಕ್ಕೆ ಯಾವುದೇ ನೇರ ಲಿಂಕ್ ಇಲ್ಲ. ಮಲ್ಟಿಟೆನೆನ್ಸಿ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಕಾರ್ಪೊರೇಟ್ ಅಥವಾ ಇಲಾಖಾ ಐಟಿ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಒಂದೇ ರೀತಿಯ ಶಾಖೆಗಳು ಮತ್ತು ಹಿಡುವಳಿ ಉದ್ಯಮಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಬಳಸಬಹುದು.
ಬಹುತ್ವವು ಕೇವಲ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯನ್ನು ಸಂಘಟಿಸುವ ವಿಷಯವಲ್ಲ ಎಂದು ನಾವು ಹೇಳಬಹುದು. ಇದು ಒಟ್ಟಾರೆಯಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಮಾದರಿಯಾಗಿದೆ (ಅದರ ವಾಸ್ತುಶಿಲ್ಪದ ಗಮನಾರ್ಹ ಭಾಗ, ಅದರ ನಿಯೋಜನೆ ಮಾದರಿ ಮತ್ತು ಅದರ ನಿರ್ವಹಣೆ ಸಂಸ್ಥೆ ಸೇರಿದಂತೆ).
ಮಲ್ಟಿಟೆನೆನ್ಸಿ ಮಾದರಿಯ ಬಗ್ಗೆ ಅತ್ಯಂತ ಕಷ್ಟಕರವಾದ ಮತ್ತು ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವೆಂದರೆ ನಮಗೆ ತೋರುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ನ ಸಾರವು "ವಿಭಜಿಸುತ್ತದೆ". ಕ್ರಿಯಾತ್ಮಕತೆಯ ಭಾಗವು ನಿರ್ದಿಷ್ಟ ಡೇಟಾ ಪ್ರದೇಶಗಳೊಂದಿಗೆ (ಅಪಾರ್ಟ್ಮೆಂಟ್ಗಳು) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಇತರ ಅಪಾರ್ಟ್ಮೆಂಟ್ಗಳಲ್ಲಿ ನಿವಾಸಿಗಳು ಇದ್ದಾರೆ ಎಂಬ ಅಂಶದಲ್ಲಿ "ಆಸಕ್ತಿ ಹೊಂದಿಲ್ಲ". ಮತ್ತು ಕೆಲವರು ಮನೆಯನ್ನು ಒಟ್ಟಾರೆಯಾಗಿ ಗ್ರಹಿಸುತ್ತಾರೆ ಮತ್ತು ಎಲ್ಲಾ ನಿವಾಸಿಗಳಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಇವುಗಳು ಎಲ್ಲಾ ನಂತರ, ಪ್ರತ್ಯೇಕ ಅಪಾರ್ಟ್ಮೆಂಟ್ಗಳು ಎಂಬ ಅಂಶವನ್ನು ನಿರ್ಲಕ್ಷಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಅಗತ್ಯ ಮಟ್ಟದ ಗ್ರ್ಯಾನ್ಯುಲಾರಿಟಿ ಮತ್ತು ಭದ್ರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ.
1C: ಎಂಟರ್ಪ್ರೈಸ್ನಲ್ಲಿ, ಮಲ್ಟಿಟೆನೆನ್ಸಿ ಮಾದರಿಯನ್ನು ಹಲವಾರು ತಂತ್ರಜ್ಞಾನಗಳ ಮಟ್ಟದಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ. ಇವು 1C ಯ ಕಾರ್ಯವಿಧಾನಗಳಾಗಿವೆ: ಎಂಟರ್ಪ್ರೈಸ್ ಪ್ಲಾಟ್ಫಾರ್ಮ್, ಕಾರ್ಯವಿಧಾನಗಳು"ಮತ್ತು"", ಕಾರ್ಯವಿಧಾನಗಳು (ಪ್ರಮಾಣಿತ ಉಪವ್ಯವಸ್ಥೆಗಳ ಗ್ರಂಥಾಲಯಗಳು).
ಈ ಪ್ರತಿಯೊಂದು ಐಟಂಗಳು ಅಪಾರ್ಟ್ಮೆಂಟ್ ಕಟ್ಟಡದ ಒಟ್ಟಾರೆ ಮೂಲಸೌಕರ್ಯ ನಿರ್ಮಾಣಕ್ಕೆ ಕೊಡುಗೆ ನೀಡುತ್ತವೆ. ಇದನ್ನು ಹಲವಾರು ತಂತ್ರಜ್ಞಾನಗಳಲ್ಲಿ ಏಕೆ ಅಳವಡಿಸಲಾಗಿದೆ, ಮತ್ತು ಒಂದರಲ್ಲಿ ಅಲ್ಲ, ಉದಾಹರಣೆಗೆ, ವೇದಿಕೆಯಲ್ಲಿ? ಮೊದಲನೆಯದಾಗಿ, ಕೆಲವು ಕಾರ್ಯವಿಧಾನಗಳು, ನಮ್ಮ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ನಿರ್ದಿಷ್ಟ ನಿಯೋಜನೆ ಆಯ್ಕೆಗಾಗಿ ಮಾರ್ಪಡಿಸಲು ಸಾಕಷ್ಟು ಸೂಕ್ತವಾಗಿದೆ. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ, ಇದು ಕಷ್ಟಕರವಾದ ಪ್ರಶ್ನೆಯಾಗಿದೆ, ಮತ್ತು ನಾವು ನಿರಂತರವಾಗಿ ಒಂದು ಆಯ್ಕೆಯನ್ನು ಎದುರಿಸುತ್ತೇವೆ - ಬಹುತ್ವದ ಈ ಅಥವಾ ಆ ಅಂಶವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಯಾವ ಮಟ್ಟದಲ್ಲಿ ಉತ್ತಮವಾಗಿದೆ.
ನಿಸ್ಸಂಶಯವಾಗಿ, ಪ್ಲಾಟ್ಫಾರ್ಮ್ನಲ್ಲಿ ಕಾರ್ಯವಿಧಾನಗಳ ಮೂಲಭೂತ ಭಾಗವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗಿದೆ. ಸರಿ, ಉದಾಹರಣೆಗೆ, ನಿಜವಾದ ಡೇಟಾ ಬೇರ್ಪಡಿಕೆ. ಇಲ್ಲಿ ಜನರು ಸಾಮಾನ್ಯವಾಗಿ ಬಹುತ್ವದ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಆದರೆ ಕೊನೆಯಲ್ಲಿ, ಮಲ್ಟಿಟೆನೆನ್ಸಿ ಮಾದರಿಯು ಪ್ಲಾಟ್ಫಾರ್ಮ್ನ ಕಾರ್ಯವಿಧಾನಗಳ ಗಮನಾರ್ಹ ಭಾಗದ ಮೂಲಕ "ಪ್ರಯಾಣ" ಮಾಡಿತು ಮತ್ತು ಅವುಗಳ ಪರಿಷ್ಕರಣೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಮರುಚಿಂತನೆ.
ವೇದಿಕೆಯ ಮಟ್ಟದಲ್ಲಿ, ನಾವು ಮೂಲಭೂತ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ನಿಖರವಾಗಿ ಅಳವಡಿಸಿದ್ದೇವೆ. ಮಲ್ಟಿಟೆನೆನ್ಸಿ ಮಾದರಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ರಚಿಸಲು ಅವು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ. ಆದರೆ ಅಂತಹ ಮಾದರಿಯಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ಗಳು "ಲೈವ್ ಮತ್ತು ಕೆಲಸ" ಮಾಡಲು, ನೀವು ಅವರ "ಜೀವನ ಚಟುವಟಿಕೆಗಳನ್ನು" ನಿರ್ವಹಿಸುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿರಬೇಕು. 1cFresh ತಂತ್ರಜ್ಞಾನಗಳು ಮತ್ತು BSP ಮಟ್ಟದಲ್ಲಿ ಏಕೀಕೃತ ವ್ಯಾಪಾರ ತರ್ಕ ಪದರವು ಇದಕ್ಕೆ ಕಾರಣವಾಗಿದೆ. ಅಪಾರ್ಟ್ಮೆಂಟ್ ಕಟ್ಟಡದಲ್ಲಿ ಮೂಲಸೌಕರ್ಯವು ನಿವಾಸಿಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ಒದಗಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ 1cFresh ತಂತ್ರಜ್ಞಾನಗಳು ಮಲ್ಟಿಟೆನೆನ್ಸಿ ಮಾದರಿಯಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ಒದಗಿಸುತ್ತದೆ. ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ಗಳು ಈ ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಬಹುದು (ಗಮನಾರ್ಹ ಮಾರ್ಪಾಡುಗಳಿಲ್ಲದೆ), ಅನುಗುಣವಾದ “ಕನೆಕ್ಟರ್ಗಳನ್ನು” ಅವುಗಳಲ್ಲಿ ಬಿಎಸ್ಪಿ ಉಪವ್ಯವಸ್ಥೆಗಳ ರೂಪದಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ.
ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಕಾರ್ಯವಿಧಾನಗಳ ದೃಷ್ಟಿಕೋನದಿಂದ, ನಾವು ಅನುಭವವನ್ನು ಗಳಿಸಿದಂತೆ ಮತ್ತು ಕ್ಲೌಡ್ ಬಳಕೆಯ ಪ್ರಕರಣವನ್ನು "1C: ಎಂಟರ್ಪ್ರೈಸ್" ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದಾಗ, ನಾವು ಈ ಆರ್ಕಿಟೆಕ್ಚರ್ನಲ್ಲಿ ಒಳಗೊಂಡಿರುವ ಕಾರ್ಯವಿಧಾನಗಳ ಸಂಯೋಜನೆಯನ್ನು ವಿಸ್ತರಿಸುತ್ತಿದ್ದೇವೆ ಎಂದು ಗಮನಿಸುವುದು ಸುಲಭ. ಒಂದು ಉದಾಹರಣೆ ಕೊಡೋಣ. ಮಲ್ಟಿಟೆನೆನ್ಸಿ ಮಾದರಿಯಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್ ಸೇವೆಯಲ್ಲಿ ಭಾಗವಹಿಸುವವರ ಪಾತ್ರಗಳು ಗಮನಾರ್ಹವಾಗಿ ಬದಲಾಗುತ್ತವೆ. ಆಪರೇಟಿಂಗ್ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವವರ ಪಾತ್ರ (ಜವಾಬ್ದಾರಿಯ ಮಟ್ಟ) ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಹೆಚ್ಚು ಶಕ್ತಿಯುತವಾದ ಅಪ್ಲಿಕೇಶನ್ ನಿಯಂತ್ರಣ ಸಾಧನಗಳನ್ನು ಹೊಂದಿರುವುದು ಅವರಿಗೆ ಅಗತ್ಯವಾಯಿತು. ಏಕೆಂದರೆ ಅಪ್ಲಿಕೇಶನ್ ಬಳಕೆದಾರರು (ನಿವಾಸಿಗಳು) ಅವರು ಕೆಲಸ ಮಾಡುವ ಎಲ್ಲಾ ಪೂರೈಕೆದಾರರನ್ನು ಮೊದಲು ನಂಬುತ್ತಾರೆ. ಇದನ್ನು ಮಾಡಲು, ನಾವು ಹೊಸದನ್ನು ಜಾರಿಗೆ ತಂದಿದ್ದೇವೆ . ಈ ಕಾರ್ಯವಿಧಾನವು ಒದಗಿಸುವವರ ನಿರ್ವಾಹಕರಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್ಗಳ ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ಅಗತ್ಯವಿರುವ ಮಟ್ಟದ ಸುರಕ್ಷತೆಗೆ ಮಿತಿಗೊಳಿಸಲು ಅನುಮತಿಸುತ್ತದೆ - ಮೂಲಭೂತವಾಗಿ, ನಿರ್ದಿಷ್ಟ ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ನಲ್ಲಿ ಪ್ರತಿ ಬಾಡಿಗೆದಾರರಿಗೆ ಅಪ್ಲಿಕೇಶನ್ನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು.
ಮಲ್ಟಿಟೆನೆನ್ಸಿ ಮೋಡ್ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಆರ್ಕಿಟೆಕ್ಚರ್ ಕಡಿಮೆ ಆಸಕ್ತಿದಾಯಕವಲ್ಲ (ಏನು 1cFresh ಮತ್ತು BSP ತಂತ್ರಜ್ಞಾನಗಳಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ). ಇಲ್ಲಿ, ಸಾಂಪ್ರದಾಯಿಕ ನಿಯೋಜನೆ ಮಾದರಿಗೆ ಹೋಲಿಸಿದರೆ, ನಿರ್ವಹಣಾ ಪ್ರಕ್ರಿಯೆಗಳ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಅಗತ್ಯತೆಗಳು ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತವೆ. ಅಂತಹ ಹಲವಾರು ಪ್ರಕ್ರಿಯೆಗಳಿವೆ: ಹೊಸ ಡೇಟಾ ಪ್ರದೇಶಗಳನ್ನು ರಚಿಸುವುದು ("ಅಪಾರ್ಟ್ಮೆಂಟ್ಗಳು"), ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನವೀಕರಿಸುವುದು, ನಿಯಂತ್ರಕ ಮಾಹಿತಿಯನ್ನು ನವೀಕರಿಸುವುದು, ಬ್ಯಾಕ್ಅಪ್ಗಳು, ಇತ್ಯಾದಿ. ಮತ್ತು, ಸಹಜವಾಗಿ, ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ಲಭ್ಯತೆಯ ಮಟ್ಟಕ್ಕೆ ಅಗತ್ಯತೆಗಳು ಹೆಚ್ಚುತ್ತಿವೆ. ಉದಾಹರಣೆಗೆ, ಅಪ್ಲಿಕೇಶನ್ಗಳು ಮತ್ತು ನಿಯಂತ್ರಣ ಸಿಸ್ಟಮ್ ಘಟಕಗಳ ನಡುವಿನ ವಿಶ್ವಾಸಾರ್ಹ ಸಂವಹನವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನಾವು ಖಾತರಿಪಡಿಸಿದ ವಿತರಣೆಯೊಂದಿಗೆ ಅಸಮಕಾಲಿಕ ಕರೆ ಸಿಸ್ಟಮ್ ತಂತ್ರಜ್ಞಾನವನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ.
ಬಹಳ ಸೂಕ್ಷ್ಮವಾದ ಅಂಶವೆಂದರೆ ಡೇಟಾ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸಾಮಾಜಿಕಗೊಳಿಸುವ ಮಾರ್ಗವಾಗಿದೆ. ಇದು ಮೊದಲ ನೋಟದಲ್ಲಿ ಮಾತ್ರ ಸರಳವಾಗಿದೆ (ಅದು ಯಾರಿಗಾದರೂ ತೋರುತ್ತಿದ್ದರೆ). ಡೇಟಾ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳ ಕೇಂದ್ರೀಕರಣ ಮತ್ತು ವಿಕೇಂದ್ರೀಕರಣದ ನಡುವಿನ ಸಮತೋಲನವು ದೊಡ್ಡ ಸವಾಲು. ಒಂದೆಡೆ, ಕೇಂದ್ರೀಕರಣವು ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ (ಡಿಸ್ಕ್ ಸ್ಪೇಸ್, ಪ್ರೊಸೆಸರ್ ಸಂಪನ್ಮೂಲಗಳು, ನಿರ್ವಾಹಕರ ಪ್ರಯತ್ನಗಳು ...). ಮತ್ತೊಂದೆಡೆ, ಇದು "ಬಾಡಿಗೆದಾರರ" ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ನ "ವಿಭಜನೆ" ಯ ಕ್ಷಣಗಳಲ್ಲಿ ಇದು ನಿಖರವಾಗಿ ಒಂದಾಗಿದೆ, ಡೆವಲಪರ್ ಕಿರಿದಾದ ಅರ್ಥದಲ್ಲಿ (ಒಂದು "ಅಪಾರ್ಟ್ಮೆಂಟ್" ಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವುದು) ಮತ್ತು ವಿಶಾಲ ಅರ್ಥದಲ್ಲಿ (ಎಲ್ಲಾ "ಬಾಡಿಗೆದಾರರಿಗೆ" ಏಕಕಾಲದಲ್ಲಿ ಸೇವೆ ಸಲ್ಲಿಸುವುದು) ಅಪ್ಲಿಕೇಶನ್ನ ಬಗ್ಗೆ ಏಕಕಾಲದಲ್ಲಿ ಯೋಚಿಸಬೇಕಾದಾಗ. .
ಅಂತಹ "ಸಂದಿಗ್ಧತೆ" ಯ ಉದಾಹರಣೆಯಾಗಿ, ಒಬ್ಬರು ನಿಯಂತ್ರಕ ಮತ್ತು ಉಲ್ಲೇಖ ಮಾಹಿತಿಯನ್ನು ಉಲ್ಲೇಖಿಸಬಹುದು. ಸಹಜವಾಗಿ, ಮನೆಯ ಎಲ್ಲಾ "ಬಾಡಿಗೆದಾರರಿಗೆ" ಸಾಮಾನ್ಯವಾಗಲು ಒಂದು ದೊಡ್ಡ ಪ್ರಲೋಭನೆ ಇದೆ. ಇದನ್ನು ಒಂದೇ ನಕಲಿನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಎಲ್ಲರಿಗೂ ಒಂದೇ ಬಾರಿಗೆ ನವೀಕರಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಆದರೆ ಕೆಲವು ನಿವಾಸಿಗಳಿಗೆ ನಿರ್ದಿಷ್ಟ ಬದಲಾವಣೆಗಳು ಬೇಕಾಗುತ್ತವೆ ಎಂದು ಅದು ಸಂಭವಿಸುತ್ತದೆ. ವಿಚಿತ್ರವೆಂದರೆ, ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದು ಸಂಭವಿಸುತ್ತದೆ, ನಿಯಂತ್ರಕರು (ಸರ್ಕಾರಿ ಸಂಸ್ಥೆಗಳು) ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮಾಹಿತಿಗೆ ಸಹ. ಇದು ಕಷ್ಟಕರವಾದ ಪ್ರಶ್ನೆಯಾಗಿ ಹೊರಹೊಮ್ಮುತ್ತದೆ: ಬೆರೆಯಲು ಅಥವಾ ಬೆರೆಯಲು ಇಲ್ಲವೇ? ಎಲ್ಲರಿಗೂ ಸಾಮಾನ್ಯ ಮಾಹಿತಿಯನ್ನು ಮತ್ತು ಅದನ್ನು ಬಯಸುವವರಿಗೆ ಖಾಸಗಿಯಾಗಿ ಮಾಡಲು ಇದು ಪ್ರಲೋಭನಕಾರಿಯಾಗಿದೆ. ಮತ್ತು ಇದು ಈಗಾಗಲೇ ಬಹಳ ಕಷ್ಟಕರವಾದ ಅನುಷ್ಠಾನಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ಆದರೆ ನಾವು ಈ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ ...
ನಿಯಮಿತ ಪ್ರಕ್ರಿಯೆಗಳ ಅನುಷ್ಠಾನದ ವಿನ್ಯಾಸವು ಮತ್ತೊಂದು ಉದಾಹರಣೆಯಾಗಿದೆ (ವೇಳಾಪಟ್ಟಿಯಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ, ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯಿಂದ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ, ಇತ್ಯಾದಿ). ಒಂದೆಡೆ, ಅವುಗಳನ್ನು ಪ್ರತಿ ಡೇಟಾ ಪ್ರದೇಶಕ್ಕೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಇದು ಸುಲಭ ಮತ್ತು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿದೆ. ಆದರೆ, ಮತ್ತೊಂದೆಡೆ, ಅಂತಹ ಉತ್ತಮವಾದ ಗ್ರ್ಯಾನ್ಯುಲಾರಿಟಿ ಸಿಸ್ಟಮ್ನಲ್ಲಿ ದೊಡ್ಡ ಹೊರೆ ಸೃಷ್ಟಿಸುತ್ತದೆ. ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ನೀವು ಸಾಮಾಜಿಕ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗಿದೆ. ಆದರೆ ಅವರಿಗೆ ಹೆಚ್ಚು ಎಚ್ಚರಿಕೆಯಿಂದ ಅಧ್ಯಯನದ ಅಗತ್ಯವಿದೆ.
ಸಹಜವಾಗಿ, ಇದು ಬಹಳ ಮಹತ್ವದ ಪ್ರಶ್ನೆಯನ್ನು ಹುಟ್ಟುಹಾಕುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್ಗಳು ಬಹುತ್ವವನ್ನು ಹೇಗೆ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು? ಇದಕ್ಕಾಗಿ ಅವರು ಏನು ಮಾಡಬೇಕು? ಸಹಜವಾಗಿ, ತಾಂತ್ರಿಕ ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ಸಮಸ್ಯೆಗಳ ಹೊರೆಯು ಸರಬರಾಜು ಮಾಡಿದ ತಂತ್ರಜ್ಞಾನದ ಭುಜದ ಮೇಲೆ ಸಾಧ್ಯವಾದಷ್ಟು ಬೀಳುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್ ವ್ಯವಹಾರ ತರ್ಕ ಕಾರ್ಯಗಳ ವಿಷಯದಲ್ಲಿ ಮಾತ್ರ ಯೋಚಿಸುತ್ತಾರೆ. ಆದರೆ ಇತರ ಪ್ರಮುಖ ವಾಸ್ತುಶಿಲ್ಪದ ಸಮಸ್ಯೆಗಳಂತೆ, ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್ಗಳು ಮಲ್ಟಿಟೆನೆನ್ಸಿ ಮಾದರಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ತಿಳುವಳಿಕೆಯನ್ನು ಹೊಂದಿರಬೇಕು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ ಸ್ವಲ್ಪ ಪ್ರಯತ್ನದ ಅಗತ್ಯವಿರುತ್ತದೆ. ಏಕೆ? ಏಕೆಂದರೆ ಡೇಟಾದ ಸೆಮ್ಯಾಂಟಿಕ್ಸ್ ಅನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳದೆ ತಂತ್ರಜ್ಞಾನವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಒದಗಿಸಲಾಗದ ಅಂಶಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, ಮಾಹಿತಿ ಸಾಮಾಜಿಕೀಕರಣದ ಗಡಿಗಳ ಅದೇ ವ್ಯಾಖ್ಯಾನ. ಆದರೆ ನಾವು ಈ ತೊಂದರೆಗಳನ್ನು ಚಿಕ್ಕದಾಗಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಅಂತಹ ಅಪ್ಲಿಕೇಶನ್ಗಳ ಅನುಷ್ಠಾನದ ಉದಾಹರಣೆಗಳಿವೆ.
1C: ಎಂಟರ್ಪ್ರೈಸ್ನಲ್ಲಿ ಮಲ್ಟಿಟೆನೆನ್ಸಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಂದರ್ಭದಲ್ಲಿ ಒಂದು ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ನಾವು ಹೈಬ್ರಿಡ್ ಮಾದರಿಯನ್ನು ರಚಿಸುತ್ತಿದ್ದೇವೆ, ಇದರಲ್ಲಿ ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಮಲ್ಟಿಟೆನೆನ್ಸಿ ಮೋಡ್ ಮತ್ತು ಸಾಮಾನ್ಯ ಮೋಡ್ ಎರಡರಲ್ಲೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ತುಂಬಾ ಕಷ್ಟಕರವಾದ ಕೆಲಸ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಚರ್ಚೆಯ ವಿಷಯವಾಗಿದೆ.
ಮೂಲ: www.habr.com
