კლასიკური კლიენტ-სერვერის არქიტექტურა

ტერმინი "კლიენტ-სერვერი" ეხება ამ არქიტექტურას პროგრამული პაკეტი, რომელშიც მისი ფუნქციური ნაწილები ურთიერთქმედებენ მოთხოვნა-პასუხის სქემის მიხედვით. თუ განვიხილავთ ამ კომპლექსის ორ ურთიერთდაკავშირებულ ნაწილს, მაშინ ერთ-ერთი მათგანი (კლიენტი) ასრულებს აქტიური ფუნქცია, ანუ იწყებს მოთხოვნებს, ხოლო მეორე (სერვერი) პასიურად პასუხობს მათ. როგორც სისტემა ვითარდება, როლები შეიძლება შეიცვალოს, მაგალითად, ზოგიერთი პროგრამის ბლოკიერთდროულად შეასრულებს სერვერის ფუნქციებს ერთ ბლოკთან მიმართებაში და კლიენტის ფუნქციებს მეორესთან მიმართებაში.

გაითვალისწინეთ, რომ ნებისმიერი საინფორმაციო სისტემაუნდა ჰქონდეს მინიმუმ სამი ძირითადი ფუნქციური ნაწილი - მოდული მონაცემთა შენახვის, მონაცემთა დამუშავებისა და მომხმარებლის ინტერფეისისთვის. თითოეული ეს ნაწილი შეიძლება განხორციელდეს დანარჩენი ორისგან დამოუკიდებლად. მაგალითად, მონაცემთა შესანახად და დასამუშავებლად გამოყენებული პროგრამების შეცვლის გარეშე, შეგიძლიათ შეცვალოთ მომხმარებლის ინტერფეისი ისე, რომ იგივე მონაცემები გამოჩნდეს ცხრილების, გრაფიკების ან ჰისტოგრამების სახით. მონაცემთა პრეზენტაციისა და შენახვის პროგრამების შეცვლის გარეშე, შეგიძლიათ შეცვალოთ დამუშავების პროგრამები, მაგალითად, ალგორითმის შეცვლით სრული ტექსტის ძებნა. დაბოლოს, მონაცემთა წარდგენისა და დამუშავების პროგრამების შეცვლის გარეშე, შეგიძლიათ შეცვალოთ პროგრამული უზრუნველყოფა მონაცემთა შესანახად, გადაიტანოთ, მაგალითად, სხვა ფაილურ სისტემაში.

IN კლასიკური არქიტექტურაკლიენტ-სერვერმა უნდა გაანაწილოს აპლიკაციის სამი ძირითადი ნაწილი ორ ფიზიკურ მოდულზე. როგორც წესი, მონაცემთა შესანახი პროგრამული უზრუნველყოფა განთავსებულია სერვერზე (მაგალითად, მონაცემთა ბაზის სერვერი), მომხმარებლის ინტერფეისი არის კლიენტის მხარეს, მაგრამ მონაცემთა დამუშავება უნდა განაწილდეს კლიენტსა და შორის. სერვერის ნაწილები. ეს არის ორსართულიანი არქიტექტურის მთავარი ნაკლი, რაც იწვევს რამდენიმე უსიამოვნო მახასიათებელს, რაც მნიშვნელოვნად ართულებს კლიენტ-სერვერის სისტემების განვითარებას.

მონაცემთა დამუშავების ალგორითმების გაყოფისას აუცილებელია სისტემის ორივე ნაწილის ქცევის სინქრონიზაცია. ყველა დეველოპერს უნდა ჰქონდეს სრული ინფორმაციაო უახლესი ცვლილებებისისტემაში განხორციელებული ცვლილებები და გაიგეთ ეს ცვლილებები. ეს ქმნის დიდ სირთულეებს კლიენტ-სერვერის სისტემების განვითარებაში, მათ ინსტალაციასა და შენარჩუნებაში, ვინაიდან აუცილებელია მნიშვნელოვანი ძალისხმევის დახარჯვა სპეციალისტთა სხვადასხვა ჯგუფის ქმედებების კოორდინაციისთვის. წინააღმდეგობები ხშირად წარმოიქმნება დეველოპერების ქმედებებში და ეს ანელებს სისტემის განვითარებას და აიძულებს მათ შეცვალონ მზა და დადასტურებული ელემენტები.

შეუსაბამობის თავიდან ასაცილებლად სხვადასხვა ელემენტებიარქიტექტურები ცდილობენ შეასრულონ მონაცემთა დამუშავება ორიდან ერთ ფიზიკურ ნაწილზე - კლიენტის მხარეს (სქელი კლიენტი) ან სერვერზე (თხელ კლიენტი, ან არქიტექტურა, რომელსაც ეწოდება 2.5-იარუსი კლიენტ-სერვერი). თითოეულ მიდგომას აქვს თავისი ნაკლოვანებები. პირველ შემთხვევაში, ქსელი დაუსაბუთებლად გადატვირთულია, რადგან დაუმუშავებელი და, შესაბამისად, ზედმეტი მონაცემები გადაიცემა მისი მეშვეობით. გარდა ამისა, სისტემის მხარდაჭერა და მისი შეცვლა უფრო რთული ხდება, რადგან გაანგარიშების ალგორითმის შეცვლა ან შეცდომის გამოსწორება მოითხოვს ერთდროულად სრული ჩანაცვლებაყველა ინტერფეისის პროგრამა, წინააღმდეგ შემთხვევაში შეიძლება მოხდეს შეცდომები ან მონაცემთა შეუსაბამობა. თუ ყველა ინფორმაციის დამუშავება ხორციელდება სერვერზე (როდესაც ეს შესაძლებელია), მაშინ ჩნდება ჩაშენებული პროცედურების აღწერისა და მათი გამართვის პრობლემა. საქმე იმაშია, რომ ჩაშენებული პროცედურების აღწერის ენა ჩვეულებრივ დეკლარაციულია და, შესაბამისად, პრინციპში არ იძლევა საშუალებას ნაბიჯ-ნაბიჯ გამართვა. გარდა ამისა, სერვერზე ინფორმაციის დამუშავების სისტემის სხვა პლატფორმაზე გადატანა აბსოლუტურად შეუძლებელია, რაც სერიოზული ნაკლია.

უმრავლესობა თანამედროვე საშუალებებიაპლიკაციის სწრაფი განვითარება (RAD), რომელიც მუშაობს სხვადასხვა მონაცემთა ბაზაზე, ახორციელებს პირველ სტრატეგიას, ანუ სქელი კლიენტი უზრუნველყოფს ინტერფეისს მონაცემთა ბაზის სერვერთან ჩაშენებული SQL-ის საშუალებით. "სქელი" კლიენტით სისტემის დანერგვის ეს ვარიანტი, გარდა ზემოთ ჩამოთვლილი უარყოფითი მხარეებისა, ჩვეულებრივ იძლევა მიუღებელ დაბალი დონეუსაფრთხოება. მაგალითად, in საბანკო სისტემებიყველა ოპერატორს უნდა მიეცეს ჩაწერის უფლება მთავარ ცხრილზე სააღრიცხვო სისტემა. გარდა ამისა, ამ სისტემასვებ ტექნოლოგიაზე გადატანა თითქმის შეუძლებელია, რადგან მონაცემთა ბაზის სერვერზე წვდომისთვის გამოიყენება კლიენტის სპეციალიზებული პროგრამული უზრუნველყოფა.

ასე რომ, ზემოთ განხილულ მოდელებს აქვთ შემდეგი უარყოფითი მხარეები.

1. "სქელი" კლიენტი:
# ადმინისტრირების სირთულე;
# პროგრამული უზრუნველყოფის განახლება უფრო რთული ხდება, რადგან ის ერთდროულად უნდა შეიცვალოს მთელ სისტემაში;
# უფლებამოსილებების განაწილება უფრო რთული ხდება, რადგან წვდომა შეზღუდულია არა მოქმედებებით, არამედ ცხრილებით;
# ქსელი გადატვირთულია დაუმუშავებელი მონაცემების გადაცემის გამო;
# მონაცემთა სუსტი დაცვა, რადგან ძნელია უფლებამოსილების სწორად განაწილება.

2. "მსუქანი" სერვერი:
# დანერგვა უფრო რთული ხდება, რადგან ენები, როგორიცაა PL/SQL არ არის შესაფერისი ასეთი პროგრამული უზრუნველყოფის შესაქმნელად და არ არსებობს კარგი სახსრებიგამართვა;
# PL/SQL ენებზე დაწერილი პროგრამების შესრულება მნიშვნელოვნად დაბალია, ვიდრე სხვა ენებზე შექმნილი პროგრამები, რომლებსაც აქვთ მნიშვნელოვანიამისთვის რთული სისტემები;
DBMS ენებზე დაწერილი # პროგრამა ჩვეულებრივ არ მუშაობს საიმედოდ; მათში შეცდომამ შეიძლება გამოიწვიოს მონაცემთა ბაზის მთელი სერვერის უკმარისობა;
# შედეგად მიღებული პროგრამები სრულიად შეუსაბამოა სხვა სისტემებისა და პლატფორმებისთვის.

გადაწყვეტილებისთვის ჩამოთვლილი პრობლემებიგამოიყენება მრავალ დონის (სამი ან მეტი დონის) კლიენტ-სერვერის არქიტექტურები.

მრავალ დონის კლიენტ-სერვერის არქიტექტურები

ასეთი არქიტექტურები უფრო ჭკვიანურად ანაწილებენ მონაცემთა დამუშავების მოდულებს, რომლებიც ამ შემთხვევაში მუშაობს ერთ ან რამდენიმე ცალკეულ სერვერზე. ესენი პროგრამული მოდულებიასრულებს სერვერის ფუნქციებს მომხმარებლებთან ინტერფეისისთვის და კლიენტის მონაცემთა ბაზის სერვერებისთვის. გარდა ამისა, სხვადასხვა აპლიკაციის სერვერებს შეუძლიათ ერთმანეთთან კომუნიკაცია, რათა უფრო ზუსტად დაიყოს სისტემა ფუნქციურ ერთეულებად, რომლებიც ასრულებენ კონკრეტულ როლებს. მაგალითად, შეგიძლიათ აირჩიოთ პერსონალის მართვის სერვერი, რომელიც შეასრულებს პერსონალის მართვისთვის აუცილებელ ყველა ფუნქციას. მასთან დაკავშირებით ცალკე მონაცემთა ბაზამონაცემები, თქვენ შეგიძლიათ დამალოთ ამ სერვერის განხორციელების ყველა დეტალი მომხმარებლებისგან, რაც მათ საშუალებას მისცემს მხოლოდ მის საჯარო ფუნქციებზე წვდომას. გარდა ამისა, ასეთი სისტემა ძალიან ადვილად ადაპტირდება ინტერნეტთან, რადგან უფრო ადვილია მომხმარებლისთვის HTML ფორმების შემუშავება მონაცემთა ბაზის გარკვეულ ფუნქციებზე წვდომისთვის, ვიდრე ყველა მონაცემზე.

სამსაფეხურიან არქიტექტურაში თხელი კლიენტი არ არის გადატვირთული მონაცემთა დამუშავების ფუნქციებით, მაგრამ ასრულებს თავის მთავარ როლს, როგორც აპლიკაციის სერვერიდან მომდინარე ინფორმაციის წარმოდგენის სისტემა. ასეთი ინტერფეისი შეიძლება განხორციელდეს გამოყენებით სტანდარტული საშუალებებივებ ტექნოლოგიები - ბრაუზერი, CGI და Java. ეს ამცირებს კლიენტსა და აპლიკაციის სერვერს შორის გადაცემული მონაცემების რაოდენობას, რაც საშუალებას გაძლევთ დაუკავშირდეთ კლიენტის კომპიუტერებითუნდაც ნელ ხაზებზე, როგორიცაა სატელეფონო არხები. გარდა ამისა, კლიენტის ნაწილიშეიძლება იყოს ისეთი მარტივი, რომ უმეტეს შემთხვევაში ის განხორციელდება უნივერსალური ბრაუზერის გამოყენებით. მაგრამ თუ მაინც მოგიწევთ მისი შეცვლა, მაშინ ეს პროცედურა შეიძლება ჩატარდეს სწრაფად და უმტკივნეულოდ. სამსაფეხურიანი კლიენტ-სერვერის არქიტექტურა იძლევა მომხმარებლის ნებართვების უფრო ზუსტი მინიჭების საშუალებას, რადგან ისინი იღებენ წვდომის უფლებებს არა თავად მონაცემთა ბაზაზე, არამედ აპლიკაციის სერვერის გარკვეულ ფუნქციებზე. ეს ზრდის სისტემის უსაფრთხოებას (ჩვეულებრივ არქიტექტურასთან შედარებით) არა მხოლოდ განზრახ თავდასხმებისგან, არამედ პერსონალის მცდარი ქმედებებისგან.

მაგალითად, განვიხილოთ სისტემა, რომლის სხვადასხვა ნაწილი მუშაობს რამდენიმეზე დისტანციური მეგობარისხვა სერვერებიდან. დავუშვათ, რომ დეველოპერმა მიიღო სისტემის ახალი ვერსია, რომლის ინსტალაციისთვისაც ორ დონის არქიტექტურაში აუცილებელია ყველა სისტემის მოდულის ერთდროულად შეცვლა. თუ ეს არ გაკეთებულა, მაშინ ძველი კლიენტების ახალ სერვერებთან ურთიერთქმედებამ შეიძლება გამოიწვიოს არაპროგნოზირებადი შედეგები, რადგან დეველოპერები, როგორც წესი, არ ითვალისწინებენ სისტემის ასეთ გამოყენებას. სამსაფეხურიან არქიტექტურაში სიტუაცია გამარტივებულია. ფაქტია, რომ აპლიკაციის სერვერისა და მონაცემთა შენახვის სერვერის შეცვლით (ამის გაკეთება ერთდროულად მარტივია, რადგან ორივე მათგანი ჩვეულებრივ ახლოს მდებარეობს), ჩვენ დაუყოვნებლივ ვცვლით კომპლექტს. ხელმისაწვდომი სერვისები. ამრიგად, შეცდომის ალბათობა სერვერისა და კლიენტის ნაწილების ვერსიებს შორის შეუსაბამობის გამო მკვეთრად მცირდება. თუ შიგნით ახალი ვერსიათუ რომელიმე სერვისი გაქრა, მაშინ ინტერფეისის ელემენტები, რომლებიც მას ემსახურებოდა ძველი სისტემა, ისინი უბრალოდ არ იმუშავებენ. თუ სერვისის ალგორითმი შეიცვალა, ის სწორად იმუშავებს ძველი ინტერფეისითაც კი.

მრავალ დონის კლიენტ-სერვერის სისტემები საკმაოდ მარტივად შეიძლება გადავიდეს ვებ ტექნოლოგიაზე - ამისათვის საკმარისია კლიენტის ნაწილის შეცვლა უნივერსალური ან სპეციალიზებული ბრაუზერიდა შეავსეთ აპლიკაციის სერვერი ვებ სერვერით და მცირე პროგრამებისერვერის დარეკვის პროცედურები. ამ პროგრამების შესაქმნელად შეგიძლიათ გამოიყენოთ როგორც Common Gateway Interface (CGI) და სხვა თანამედროვე ტექოლოგიაჯავა.

აქვე უნდა აღინიშნოს, რომ სამ დონის სისტემაში საკმაოდ ბევრი ინფორმაცია გადაიცემა საკომუნიკაციო არხის მეშვეობით აპლიკაციის სერვერსა და მონაცემთა ბაზას შორის. თუმცა, ეს არ ანელებს გამოთვლებს, რადგან კომუნიკაცია მითითებული ელემენტებიშეიძლება მეტი გამოყენება გამოხატული ხაზები. ეს მოითხოვს მინიმალურ ძალისხმევას, რადგან ორივე სერვერი ჩვეულებრივ მდებარეობს იმავე შენობაში. ამრიგად, სისტემის მთლიანი შესრულება იზრდება - ორი განსხვავებული სერვერი ახლა მუშაობს ერთ ამოცანაზე და მათ შორის კომუნიკაცია შეიძლება განხორციელდეს უსწრაფესი ხაზების საშუალებით. მინიმალური ხარჯებისახსრები. მართალია, არსებობს ერთობლივი გამოთვლების თანმიმდევრულობის პრობლემა, რომლის გადასაჭრელადაც მოწოდებული არიან ტრანზაქციის მენეჯერები - მრავალ დონის სისტემების ახალი ელემენტები.

კლიენტ-სერვერის არქიტექტურა ახორციელებს მუშაობის მრავალ მომხმარებლის რეჟიმს და ნაწილდება, როდესაც კლიენტები და სერვერები განლაგებულია ლოკალური ან გლობალური ქსელის სხვადასხვა კვანძზე.

კლიენტ-სერვერის არქიტექტურის დიაგრამა მოიცავს პრეზენტაციის სამ დონეს: მომხმარებლის მიერ მონაცემთა წარმოდგენის (პრეზენტაციის) დონეს; აპლიკაციის მიერ მონაცემთა დამუშავების დონე და მონაცემთა ბაზასთან ურთიერთქმედების დონე. სქემის მიხედვით მომხმარებელი (კლიენტი) ერთ შემთხვევაში შეაქვს მონაცემებს, რომლებიც ზოგიერთი აპლიკაციის კონტროლისა და ტრანსფორმაციის შემდეგ მთავრდება მონაცემთა ბაზაში, მეორე შემთხვევაში კი ითხოვს მონაცემთა დამუშავებას აპლიკაციის მიერ, რომელიც წვდება მონაცემთა ბაზას საჭირო მონაცემები. საჭირო მონაცემების მიღების შემდეგ, სერვერი ამუშავებს მას და ათავსებს შედეგებს ან მონაცემთა ბაზაში, ან აძლევს მომხმარებელს მისთვის მოსახერხებელ ფორმაში (text.doc, ცხრილები, გრაფიკი), ან აკეთებს ორივეს ერთად.

კონკრეტული სქემის არჩევანი განისაზღვრება საწარმოს დისტანციური განყოფილებების ტერიტორიული განაწილების სხვადასხვა ვარიანტებით, ოპერატიული საიმედოობის, სიჩქარისა და მოვლის სიმარტივის მოთხოვნებით. ნახ.2-ში. წარმოდგენილია კლიენტ-სერვერის არქიტექტურის სხვადასხვა სქემები.

ფაილის სერვერი არქიტექტურა არის განაწილებული მონაცემთა დამუშავების უმარტივესი ვარიანტი, როდესაც სერვერზე განთავსებულია მხოლოდ მონაცემთა ფაილები, ხოლო მომხმარებლის აპლიკაციები DBMS-თან ერთად განლაგებულია კლიენტის მხარეს. ფაილური სერვერების გამოყენება ვარაუდობს, რომ ყველა მონაცემთა დამუშავება ხორციელდება სამუშაო სადგურზე, ხოლო ფაილების სერვერი მხოლოდ მონაცემთა შენახვისა და წვდომის საშუალებაა.

ორ დონის კლიენტ-სერვერი არქიტექტურა ეფუძნება მხოლოდ მონაცემთა ბაზის სერვერის გამოყენებას (DB სერვერი), როდესაც კლიენტის ნაწილი შეიცავს მონაცემთა პრეზენტაციის ფენას, ხოლო სერვერი შეიცავს მონაცემთა ბაზას DBMS-თან და აპლიკაციურ პროგრამებთან ერთად.

DB სერვერი განსხვავდება ფაილის სერვერისგან იმით შემთხვევითი წვდომის მეხსიერებაქსელის OS-ის გარდა, არსებობს ცენტრალიზებული DBMS, რომელიც უზრუნველყოფს სამუშაო სადგურების საერთო მონაცემთა ბაზის გაზიარებას, რომელიც მდებარეობს გარე მეხსიერებაში.

DB სერვერები. DB სერვერი შესაძლებელს ხდის უარი თქვას მთლიანი მონაცემთა ფაილების ქსელში გაგზავნაზე და მონაცემთა ბაზიდან გადაიტანოს მხოლოდ ის არჩევანი, რომელიც აკმაყოფილებს მომხმარებლის მოთხოვნას. ამ შემთხვევაში, შესაძლებელია მომხმარებლის განაცხადის ორ ნაწილად გაყოფა:

ერთი შესრულებულია სერვერზე და ასოცირდება მონაცემთა ბაზიდან მონაცემების მოძიებასთან და აგრეგაციასთან, ხოლო მეორე ნაწილი, რომელიც წარმოადგენს მონაცემთა ანალიზისა და გადაწყვეტილების მისაღებად, შესრულებულია კლიენტის მანქანაზე. ამრიგად, საინფორმაციო სისტემის საერთო შესრულება იზრდება სერვერისა და კლიენტის სამუშაო სადგურის გამოთვლითი რესურსების გაერთიანების შედეგად.

მონაცემთა ბაზაზე წვდომა ხდება გამოყენებით SQL ენა, რომელიც გახდა რელაციური მონაცემთა ბაზების სტანდარტი. ამიტომ, მონაცემთა ბაზის სერვერს ეწოდება SQL სერვერი, რომელსაც მხარს უჭერს ყველა რელაციური DBMS: Oracle, Informix, MS SQL, ADABAS D, InterBase, SyBase და ა.შ.

კლიენტის აპლიკაციის დანერგვა შესაძლებელია დესკტოპის DBMS-ის ენაზე (MS Access, FoxPro, Paradox, Clipper და ა.შ.). ამ შემთხვევაში, კლიენტის აპლიკაციის ურთიერთქმედება SQL სერვერთან ხორციელდება ODBC დრაივერის მეშვეობით (Open Data Base Connectivity), რომელიც უზრუნველყოფს გლობალური მონაცემთა ბაზიდან მონაცემების გადაცემის და კონვერტაციის შესაძლებლობას კლიენტის აპლიკაციის მონაცემთა ბაზის სტრუქტურაში.

Შესრულება

მომხმარებლის მონაცემები აპლიკაციის მონაცემთა ბაზა

ცენტრალიზებული

არქიტექტურა

"ფაილის სერვერი"

ორდონიანი

არქიტექტურა

"კლიენტის სერვერი"

თ სამ დონის

არქიტექტურა

"კლიენტის სერვერი"

Მრავალ დონიანი

არქიტექტურა

"კლიენტის სერვერი"

ნახ.2. CEIS-ის კლიენტ-სერვერის არქიტექტურის ვარიანტები

სამ დონის კლიენტ-სერვერი არქიტექტურა საშუალებას აძლევს აპლიკაციის პროგრამებს განთავსდეს ცალკე აპლიკაციის სერვერებზე, რომლებთანაც კლიენტის სამუშაო სადგურები ურთიერთობენ აპლიკაციის პროგრამის ინტერფეისის მეშვეობით. აპლიკაციის კლიენტის მხარე იძახებს აპლიკაციის სერვერის აუცილებელ ფუნქციებს, სახელწოდებით „სერვისები“. აპლიკაციის პროგრამები, თავის მხრივ, წვდებიან მონაცემთა ბაზის სერვერზე SQL მოთხოვნების გამოყენებით. ეს ორგანიზაცია საშუალებას გაძლევთ გაზარდოთ CEIS-ის პროდუქტიულობა და ეფექტურობა:

განმეორება ხელახალი გამოყენება ზოგადი ფუნქციებიმონაცემთა დამუშავება სხვადასხვა კლიენტის აპლიკაციებში და მნიშვნელოვნად დაზოგავს სისტემის რესურსებს;

პარალელურობა აპლიკაციის სერვერისა და მონაცემთა ბაზის სერვერის მუშაობაში და აპლიკაციის სერვერი შეიძლება იყოს ნაკლებად მძლავრი მონაცემთა ბაზის სერვერთან შედარებით;

კლიენტის საიტებიდან აპლიკაციის სერვერის მეშვეობით მონაცემთა ბაზაზე წვდომის ოპტიმიზაცია ქსელში მოთხოვნების შესრულების დისპეტჩერიზაციის გზით;

მონაცემთა დამუშავების სიჩქარისა და საიმედოობის გაზრდა რამდენიმე აპლიკაციის სერვერზე პროგრამული უზრუნველყოფის დუბლირების შედეგად, რომლებსაც შეუძლიათ ერთმანეთის ჩანაცვლება ქსელში რომელიმე მათგანის გადატვირთვის ან წარუმატებლობის შემთხვევაში;

სისტემის ადმინისტრირების ფუნქციების გადაცემა მონაცემთა ბაზის სერვერიდან მომხმარებლის წვდომის ნებართვების შესამოწმებლად აპლიკაციის სერვერზე.

მრავალ დონის კლიენტ-სერვერის არქიტექტურა შექმნილია გეოგრაფიულად განაწილებული საწარმოებისთვის. აქ არის ძალიან ბევრი ურთიერთობა კლიენტის სამუშაო სადგურებსა და აპლიკაციის სერვერებს შორის და აპლიკაციის სერვერებსა და მონაცემთა ბაზის სერვერებს შორის. ეს ორგანიზაცია იძლევა სტრუქტურულ დანაყოფებს შორის ინფორმაციის ნაკადების უფრო რაციონალური ორგანიზების საშუალებას. თითოეული აპლიკაციის სერვერი ემსახურება რომელიმე ფუნქციური ქვესისტემის საჭიროებებს და კონცენტრირებულია ქვესისტემის მთავარ სტრუქტურულ ერთეულში (გაყიდვების მართვის აპლიკაციის სერვერი გაყიდვების განყოფილებაში, მიწოდების მართვის აპლიკაციის სერვერი შესყიდვების განყოფილებაში და ა.შ.). ინტეგრირებული მონაცემთა ბაზა განთავსებულია ცალკე სერვერზე, რომელიც უზრუნველყოფს ცენტრალიზებულ შენარჩუნებას და საერთო მონაცემების ადმინისტრირებას ყველა აპლიკაციისთვის.

მონაცემთა ბაზის რამდენიმე სერვერის შენარჩუნება განსაკუთრებით მნიშვნელოვანია ფილიალის სტრუქტურის მქონე საწარმოებისთვის, როდესაც ცენტრალური ოფისი იყენებს საერთო მონაცემთა ბაზას, რომელიც შეიცავს გენერალიმარეგულირებელი მითითება (NS), დაგეგმვისა და ბიუჯეტის ინფორმაცია და კონსოლიდირებული ანგარიშგება და გეოგრაფიულად დაშორებულ ფილიალებში ის მხარდაჭერილია ეფექტურიმე მაქვს ინფორმაცია ბიზნეს პროცესების შესახებ. ფილიალებში მონაცემების დამუშავებისას კონტროლისთვის გამოიყენება ცენტრალური მონაცემთა ბაზიდან დაგეგმილი და NS ინფორმაცია, ხოლო ცენტრალურ ოფისში კონსოლიდირებული ანგარიშგების მიღება ასოცირდება ფილიალების ოპერატიულ ინფორმაციასთან.

4.3. მრავალ დონის კლიენტ-სერვერის სისტემები

კლიენტ-სერვერის ტექნოლოგია ითვლება კომპიუტერული ქსელების თანამედროვე სამყაროს ერთ-ერთ „საყრდენად“. მაგრამ პრობლემები, რისთვისაც იგი შეიქმნა, წარსულს ჩაბარდა. ახალი ამოცანები და ტექნოლოგიები მოითხოვს კლიენტ-სერვერის სისტემების პრინციპების გადახედვას. ერთ-ერთი ასეთი ტექნოლოგია მსოფლიო მასშტაბითვებ. ვებ ტექნოლოგია არის კლიენტ-სერვერის არქიტექტურის განვითარება, ე.ი. ერთი კლიენტით შეგიძლიათ დაუკავშირდეთ ბევრ სერვერს. საინფორმაციო სისტემას, გარდა ინტერფეისისა, უნდა ჰქონდეს მონაცემთა დამუშავებისა და შენახვის დონეები. ინტერნეტის დეველოპერებისთვის პრობლემაა ინტერნეტის მუშაობის კოორდინაცია სისტემის სხვა ელემენტებთან, როგორიცაა მონაცემთა ბაზები. ამ პრობლემის გადაჭრის ერთ-ერთი პერსპექტიული გზაა მრავალ დონის კლიენტ-სერვერის სისტემები.

კლასიკური კლიენტ-სერვერის სისტემა მუშაობს მოთხოვნა-პასუხის სქემის მიხედვით (ორ დონის არქიტექტურა). კლიენტი ასრულებს აქტიურ ფუნქციას (მოთხოვნებს), სერვერი პასუხობს მათ პასიურად.

ნებისმიერ საინფორმაციო სისტემას უნდა ჰქონდეს მინიმუმ სამი ფუნქციური ნაწილი - მოდული მონაცემთა შენახვის, მონაცემთა დამუშავებისა და მომხმარებლის ინტერფეისისთვის.

თითოეული ეს ნაწილი შეიძლება განხორციელდეს დანარჩენი ორისგან დამოუკიდებლად.

Მაგალითად . მონაცემთა შესანახად და დასამუშავებლად გამოყენებული პროგრამების შეცვლის გარეშე, შეგიძლიათ შეცვალოთ მომხმარებლის ინტერფეისი ისე, რომ იგივე მონაცემები გამოჩნდეს ცხრილების, გრაფიკების ან ჰისტოგრამების სახით. მონაცემთა პრეზენტაციისა და შენახვის პროგრამების შეცვლის გარეშე, შეგიძლიათ შეცვალოთ დამუშავების პროგრამები სრული ტექსტის ძიების ალგორითმის შეცვლით. მონაცემთა წარდგენისა და დამუშავების პროგრამების შეცვლის გარეშე, შეგიძლიათ შეცვალოთ მონაცემთა შესანახი პროგრამული უზრუნველყოფა სხვა ფაილურ სისტემაზე გადასვლით.

კლიენტ-სერვერის კლასიკურ არქიტექტურაში აპლიკაციის სამი ძირითადი ნაწილი განაწილებულია ორ ფიზიკურ მოდულზე. როგორც წესი, მონაცემთა შენახვის პროგრამული უზრუნველყოფა მდებარეობს სერვერზე (/: მონაცემთა ბაზის სერვერზე), მომხმარებლის ინტერფეისი არის კლიენტის მხარეს, მაგრამ მონაცემთა დამუშავება უნდა განაწილდეს კლიენტსა და სერვერის ნაწილებს შორის. ეს არის ამ არქიტექტურის მთავარი ნაკლი. მონაცემთა დამუშავების ალგორითმების დაყოფა მოითხოვს სისტემის ორივე ნაწილის მოქმედებების სინქრონიზაციას. არქიტექტურის სხვადასხვა ელემენტებს შორის შეუსაბამობის თავიდან ასაცილებლად, ისინი ცდილობენ შეასრულონ მონაცემთა დამუშავება ორიდან ერთ ნაწილზე - ან კლიენტის მხარეს (სქელი კლიენტი) ან სერვერზე (თხელი კლიენტი, ან 2.5-ფენიანი კლიენტ-სერვერი). თითოეულ მიდგომას აქვს თავისი ნაკლოვანებები: პირველ შემთხვევაშიქსელი გაუმართლებლად გადატვირთულია, რადგან ის გადასცემს ნედლეულ (ზედმეტ) მონაცემებს, რაც ართულებს სისტემის მხარდაჭერას და შეცვლას, რადგან გაანგარიშების ალგორითმის შეცვლა ან შეცდომის გამოსწორება მოითხოვს ყველა ინტერფეისის პროგრამის ერთდროულ სრულ ჩანაცვლებას, წინააღმდეგ შემთხვევაში მონაცემთა შეუსაბამობა მოჰყვება; მეორე შემთხვევაში, როცა ყველა ინფორმაციის დამუშავება ხდება სერვერზე, ჩნდება ჩაშენებული პროცედურების აღწერის და მათი გამართვის პრობლემა (აღწერილობა დეკლარაციულია და არ იძლევა ეტაპობრივად გამართვას). გარდა ამისა, სერვერზე ინფორმაციის დამუშავების სისტემის სხვა პლატფორმაზე გადატანა აბსოლუტურად შეუძლებელია.

ყველაზე თანამედროვე სწრაფი აპლიკაციის განვითარების (RAD) ინსტრუმენტები, რომლებიც მუშაობენ სხვადასხვა მონაცემთა ბაზებთან, ახორციელებენ პირველ მოდელს (სქელი კლიენტი), რომელიც უზრუნველყოფს ინტერფეისს მონაცემთა ბაზის სერვერთან SQL-ის საშუალებით უსაფრთხოება.

Მაგალითად. საბანკო სისტემებში ყველა ოპერატორ ოპერატორს აქვს უფლება ჩაწეროს სააღრიცხვო სისტემის მთავარ ცხრილზე. გარდა ამისა, ამ სისტემის გადატანა თითქმის შეუძლებელია ვებ ტექნოლოგიებზე, რადგან სპეციალიზებული კლიენტის პროგრამული უზრუნველყოფა გამოიყენება მონაცემთა ბაზის სერვერზე წვდომისთვის.

ზემოთ განხილული მოდელების უარყოფითი მხარეები:

"მსუქანი" კლიენტი

ადმინისტრირების სირთულე;

პროგრამული უზრუნველყოფის განახლების სირთულე, რადგან მისი ჩანაცვლება უნდა განხორციელდეს ერთდროულად მთელ სისტემაში;

ძალაუფლების განაწილების სირთულე, რადგან წვდომა შეზღუდულია არა მოქმედებებით, არამედ ცხრილებით;

ქსელის გადატვირთულობა დაუმუშავებელი მონაცემების გადაცემის გამო;

მონაცემთა სუსტი დაცვა.

"მსუქანი" სერვერი

განხორციელება უფრო რთული ხდება, რადგან PL/SQL ენები არ არის შესაფერისი ასეთი პროგრამული უზრუნველყოფის შესაქმნელად და არ არსებობს გამართვის ინსტრუმენტები;

პროგრამების შესრულება PL/SQL ენებზე უფრო დაბალია, ვიდრე სხვა ენებზე, რაც მნიშვნელოვანია რთული სისტემებისთვის;

DBMS ენებზე დაწერილი პროგრამები არ მუშაობს საიმედოდ, რამაც შეიძლება გამოიწვიოს მონაცემთა ბაზის მთელი სერვერის უკმარისობა;

ამ გზით შექმნილი პროგრამები სრულიად შეუსაბამოა სხვა სისტემებისა და პლატფორმებისთვის.

დ

ამ პრობლემების გადასაჭრელად გამოიყენება მრავალ დონის (სამი ან მეტი) კლიენტ-სერვერის მოდელები.

კლიენტ-სერვერის მრავალ დონის არქიტექტურები - უფრო ჭკვიანურად ანაწილებენ მონაცემთა დამუშავების მოდულებს, რომლებიც მუშაობენ ერთ ან რამდენიმე ცალკეულ სერვერზე.

ეს პროგრამული მოდულები ასრულებენ ფუნქციებს სერვერებიმომხმარებლებთან ინტერფეისისთვის და კლიენტი- მონაცემთა ბაზის სერვერებისთვის. გარდა ამისა, სხვადასხვა აპლიკაციის სერვერებს შეუძლიათ ერთმანეთთან კომუნიკაცია, რათა უფრო ზუსტად დაიყოს სისტემა ფუნქციურ ერთეულებად, რომლებიც ასრულებენ კონკრეტულ როლებს.

Მაგალითად. თქვენ შეგიძლიათ აირჩიოთ პერსონალის მართვის სერვერი, რომელიც შეასრულებს პერსონალის მართვისთვის აუცილებელ ყველა ფუნქციას. მასთან ცალკე მონაცემთა ბაზის ასოცირებით, თქვენ შეგიძლიათ დამალოთ ამ სერვერის განხორციელების ყველა დეტალი მომხმარებლებისგან, რაც საშუალებას მისცემს წვდომას მხოლოდ მის საჯაროდ ხელმისაწვდომ ფუნქციებზე. ასეთი სისტემა უფრო ადვილად ადაპტირდება ვებზე, რადგან უფრო ადვილია HTML ფორმების შემუშავება მომხმარებლის მიერ მონაცემთა ბაზის გარკვეულ ფუნქციებზე წვდომისთვის, ვიდრე ყველა მონაცემზე.

სამსაფეხურიან მოდელში თხელი კლიენტი არ არის გადატვირთული მონაცემთა დამუშავების ფუნქციებით, მაგრამ ასრულებს სისტემის მთავარ როლს აპლიკაციის სერვერიდან მომდინარე ინფორმაციის წარდგენისთვის. (ეს ინტერფეისი დანერგილია სტანდარტული ვებ ტექნოლოგიის ინსტრუმენტების გამოყენებით - ბრაუზერი, CGI და Java). ეს ამცირებს კლიენტსა და აპლიკაციის სერვერს შორის გადაცემული მონაცემების რაოდენობას, რაც ნელი სატელეფონო ხაზის მქონე კლიენტებს დაკავშირების საშუალებას აძლევს.

სამ დონის კლიენტ-სერვერის მოდელი საშუალებას გაძლევთ უფრო ზუსტად მიანიჭოთ მომხმარებლის ნებართვები, რადგან ისინი იღებენ უფლებებს არა თავად მონაცემთა ბაზაზე, არამედ აპლიკაციის სერვერის გარკვეულ ფუნქციებზე, რაც ზრდის სისტემის უსაფრთხოებას.

მრავალ დონის კლიენტ-სერვერის სისტემები შეიძლება ადვილად გადავიდეს ვებ ტექნოლოგიაზე - ამისათვის საკმარისია კლიენტის ნაწილის შეცვლა. უნივერსალური ბრაუზერიდა შეავსეთ აპლიკაციის სერვერი ვებ სერვერით და მცირე სერვერის პროცედურების ზარის პროგრამებით. სამ დონის სისტემაში ბევრი ინფორმაცია გადადის საკომუნიკაციო არხის საშუალებით განაცხადის სერვერსა და მონაცემთა ბაზას შორის, მაგრამ გამოთვლები არ ნელდება, რადგან უფრო სწრაფი ხაზები გამოიყენება ამ ელემენტების კომუნიკაციისთვის. ეს მოითხოვს დაბალ ხარჯებს, რადგან ორივე სერვერი განლაგებულია იმავე ოთახში. მაგრამ ეს აჩენს ერთობლივი გამოთვლების თანმიმდევრულობის პრობლემას, რომლის გადაჭრასაც ტრანზაქციის მენეჯერები - მრავალ დონის სისტემების ახალი ელემენტები - მოუწოდებენ.

სახელმწიფო და საზოგადოება საფუძველიპერსპექტიული ინფორმაცია ტექნოლოგიები; – ფორმირების პროცესები... 2. ინფორმაცია ტექნოლოგიები საბოლოო მომხმარებელი. ტექნოლოგიები ღია სისტემები. ქსელი საინფორმაციო ტექნოლოგიები 2.1. ინფორმაცია ტექნოლოგიებისაბოლოო...

კლიენტ-სერვერის ორ დონის IS არქიტექტურა

ძირითადი განსხვავებაკლიენტ-სერვერის არქიტექტურა ფაილ-სერვერის არქიტექტურიდან არის აბსტრაქცია მონაცემთა შიდა წარმოდგენიდან (ფიზიკური მონაცემთა სქემა). ასეთი არქიტექტურით კლიენტის პროგრამებიმონაცემების დონეზე მანიპულირება ლოგიკური წრე. კლიენტ-სერვერის არქიტექტურის განსახორციელებლად, ჩვეულებრივ გამოიყენება მრავალ მომხმარებლის DBMS, მაგალითად, Oracle ან Microsoft SQLსერვერი.

კლიენტ-სერვერის საინფორმაციო სისტემა შედგება სამი ძირითადი კომპონენტისგან: სერვერის პროგრამული უზრუნველყოფა; საბოლოო მომხმარებლის პროგრამული უზრუნველყოფა; შუალედური პროგრამა (ნახ. 1.7). სერვერის პროგრამული უზრუნველყოფა, გარდა მონაცემთა ბაზის მართვისა, უზრუნველყოფს მომხმარებლის მომსახურებას.

ასეთი DBMS უზრუნველყოფს ჩაკეტვის მექანიზმებს და მრავალ მომხმარებლის წვდომის კონტროლს, რომელიც იცავს მონაცემებს ერთდროულად წვდომის თანდაყოლილი რისკებისგან. გარდა ამისა, მონაცემთა ბაზის სერვერმა უნდა დაიცვას მონაცემები არაავტორიზებული წვდომისგან, მონაცემთა ბაზის მოთხოვნების ოპტიმიზაცია, მონაცემთა მთლიანობის უზრუნველყოფა და ტრანზაქციების დასრულება კონტროლი. კლიენტ-სერვერის ორგანიზაციაში კლიენტები შეიძლება იყოს საკმაოდ გამხდარი, მაგრამ სერვერი უნდა იყოს საკმარისად სქელი, რომ დააკმაყოფილოს ყველა კლიენტის საჭიროება, რომელიც მოიცავს განვითარების ინსტრუმენტებს აპლიკაციის პროგრამებიდა ანგარიშის გენერატორები, მათ შორის ცხრილებიდა ტექსტის დამმუშავებლებიამის დახმარებით პროგრამული უზრუნველყოფამომხმარებლები ამყარებენ კავშირს სერვერთან, ქმნიან შეკითხვებს, რომლებიც ავტომატურად გენერირდება SQL-ში შეკითხვებად და იგზავნება სერვერზე. სერვერი იღებს და ამუშავებს მოთხოვნებს, შემდეგ კი შედეგებს გადასცემს კლიენტებს. Middleware არის კლიენტ-სერვერის სისტემის ნაწილი, რომელიც აკავშირებს საბოლოო მომხმარებლის პროგრამულ უზრუნველყოფას სერვერთან.

კლიენტ-სერვერის არქიტექტურის გამოყენებამ შესაძლებელი გახადა საიმედო (მონაცემთა მთლიანობის თვალსაზრისით) მრავალ მომხმარებლის IS-ის შექმნა. ცენტრალიზებული ბაზამონაცემები, დამოუკიდებელი მონაცემთა ბაზის სერვერის ტექნიკის (და ხშირად პროგრამული უზრუნველყოფის) ნაწილისა და დამხმარე GUIმომხმარებელი დაკავშირებული კლიენტის სადგურებზე ლოკალური ქსელი. გარდა ამისა, მნიშვნელოვნად შემცირდა აპლიკაციის შემუშავების ხარჯები.

ამ არქიტექტურას აქვს ორი დონე, დამახასიათებელი თვისებარაც არის ის, რომ კლიენტის პროგრამები მუშაობენ მონაცემებთან სერვერის პროგრამული უზრუნველყოფის მოთხოვნით და ძირითადი ფუნქციებიაპლიკაციები იყოფა კლიენტსა და სერვერს შორის (ნახ. 1.8).

ამ არქიტექტურის უპირატესობებში შედის:

· სრული დახმარებამრავალ მომხმარებლის მუშაობა;

· მონაცემთა მთლიანობის უზრუნველყოფა.

მიზანშეწონილია გამოიყენოთ ორ დონის არქიტექტურა საწარმოებში, სადაც რამდენიმე ათეული მომხმარებელია, რადგან სერვერის ოპერაციული სისტემა შენარჩუნების დროს დიდი რაოდენობითკლიენტებს გადატვირთული აქვთ სერვერთან მრავალი კავშირის მართვა.

ორი დონის კლიენტ-სერვერის არქიტექტურის უარყოფითი მხარეა:

· აპლიკაციების ბიზნეს ლოგიკა დარჩა კლიენტის პროგრამულ უზრუნველყოფაში. ალგორითმების ნებისმიერი ცვლილებისას აუცილებელია მომხმარებლის პროგრამული უზრუნველყოფის განახლება თითოეულ კლიენტზე.

· მაღალი მოთხოვნები გამტარუნარიანობასაკომუნიკაციო არხები სერვერთან, რაც ხელს უშლის კლიენტის სადგურების გამოყენებას ლოკალური ქსელის გარდა.

· მონაცემთა სუსტი დაცვა ჰაკერებისგან, განსაკუთრებით სისტემის არაკეთილსინდისიერი მომხმარებლებისგან.

· სისტემის მომხმარებლის სამუშაო სადგურების ადმინისტრირებისა და კონფიგურაციის მაღალი სირთულე.

· კლიენტის საიტებზე ძლიერი კომპიუტერების გამოყენების აუცილებლობა.

· სისტემის განვითარების მაღალი სირთულე ბიზნეს ლოგიკის დანერგვისა და უზრუნველყოფის აუცილებლობის გამო მომხმარებლის ინტერფეისიერთ პროგრამაში.

უპირატესობები

· შესაძლებელს ხდის უმეტეს შემთხვევაში ფუნქციების განაწილებას გამოთვლითი სისტემარამდენიმე დამოუკიდებელ კომპიუტერს შორის ქსელში. ეს აადვილებს კომპიუტერული სისტემის შენარჩუნებას. კერძოდ, სერვერის შეცვლა, შეკეთება, განახლება ან გადაადგილება არ მოქმედებს მომხმარებლებზე.

· ყველა მონაცემი ინახება სერვერზე, რომელიც, როგორც წესი, ბევრად უკეთ არის დაცული ვიდრე კლიენტების უმეტესობა. უფრო ადვილია სერვერზე ნებართვის კონტროლის აღსრულება, რათა მხოლოდ კლიენტებს, რომლებსაც აქვთ შესაბამისი წვდომის უფლებები, დაუშვან მონაცემების წვდომა.

· საშუალებას გაძლევთ დააკავშიროთ სხვადასხვა კლიენტები. კლიენტებს სხვადასხვა ტექნიკის პლატფორმებით, ოპერაციული სისტემებით და ა.შ. ხშირად შეუძლიათ ერთი სერვერის რესურსების გამოყენება.

ხარვეზები

· სერვერის უკმარისობამ შეიძლება გამოიწვიოს მთელი კომპიუტერული ქსელი უფუნქციოდ.

· ამ სისტემის მუშაობის ხელშეწყობას სჭირდება ცალკე სპეციალისტი - სისტემის ადმინისტრატორი.

· აღჭურვილობის მაღალი ღირებულება.

მრავალ დონის კლიენტ-სერვერის არქიტექტურა

მრავალ დონის კლიენტ-სერვერის არქიტექტურა არის კლიენტ-სერვერის არქიტექტურის ტიპი, რომელშიც მონაცემთა დამუშავების ფუნქცია ხორციელდება ერთ ან რამდენიმე ცალკეულ სერვერზე. ეს საშუალებას გაძლევთ გამოყოთ მონაცემების შენახვის, დამუშავებისა და წარდგენის ფუნქციები ეფექტური გამოყენებასერვერებისა და კლიენტების შესაძლებლობები.

მრავალ დონის არქიტექტურის განსაკუთრებული შემთხვევები:

IN კომპიუტერული ტექნოლოგიებისამსაფეხურიანი არქიტექტურა, სინონიმი სამსაფეხურიანი ან მრავალსართულიანი არქიტექტურისა, ითვალისწინებს შემდეგი აპლიკაციის კომპონენტების არსებობას: კლიენტის აპლიკაცია(ჩვეულებრივ ამბობენ" თხელი კლიენტი"ან ტერმინალი) დაკავშირებულია აპლიკაციის სერვერთან, რომელიც თავის მხრივ დაკავშირებულია მონაცემთა ბაზის სერვერთან.

არქიტექტურის მიმოხილვა

კლიენტიარის ინტერფეისი (ჩვეულებრივ გრაფიკული) კომპონენტი, რომელიც წარმოადგენს პირველ დონეს, რეალურ აპლიკაციას საბოლოო მომხმარებლისთვის. პირველ დონეს არ უნდა ჰქონდეს პირდაპირი კავშირები მონაცემთა ბაზასთან (უსაფრთხოების მიზეზების გამო), დატვირთული იყოს ძირითადი ბიზნეს ლოგიკით (მაშტაბურობის მიზეზების გამო) და შეინახოს განაცხადის მდგომარეობა (სანდოობის მიზეზების გამო). უმარტივესი ბიზნეს ლოგიკა შეიძლება იყოს და, როგორც წესი, განთავსდება პირველ დონეზე: ავტორიზაციის ინტერფეისი, დაშიფვრის ალგორითმები, შეყვანილი მნიშვნელობების შემოწმება და ფორმატთან შესაბამისობა, მარტივი ოპერაციები (დახარისხება, დაჯგუფება, მნიშვნელობების დათვლა) უკვე მონაცემებით. ტერმინალზე დატვირთული.

განაცხადის სერვერი მდებარეობს მეორე დონეზე. მეორე დონე შეიცავს ბიზნეს ლოგიკის უმეტეს ნაწილს. მის გარეთ არის ტერმინალებში ექსპორტირებული ფრაგმენტები (იხ. ზემოთ), ასევე შენახული პროცედურები და ტრიგერები ჩაძირულია მესამე დონეზე.

მონაცემთა ბაზის სერვერი უზრუნველყოფს მონაცემთა შენახვას და გადადის მესამე დონეზე. როგორც წესი, ეს არის სტანდარტული რელაციური ან ობიექტზე ორიენტირებული DBMS. თუ მესამე დონე არის მონაცემთა ბაზა შენახულ პროცედურებთან ერთად, ტრიგერები და სქემა, რომელიც აღწერს აპლიკაციას ურთიერთობითი მოდელი, შემდეგ მეორე დონე აგებულია როგორც პროგრამული ინტერფეისი, რომელიც აკავშირებს კლიენტის კომპონენტებს მონაცემთა ბაზის აპლიკაციის ლოგიკასთან.

უმარტივეს კონფიგურაციაში, აპლიკაციის სერვერი ფიზიკურად შეიძლება გაერთიანდეს მონაცემთა ბაზის სერვერთან ერთ კომპიუტერზე, რომელსაც ერთი ან მეტი ტერმინალი უკავშირდება ქსელის მეშვეობით.

"სწორი" (უსაფრთხოების, საიმედოობის, სკალირების თვალსაზრისით) კონფიგურაციის პირობებში, მონაცემთა ბაზის სერვერი განლაგებულია სპეციალურ კომპიუტერზე (ან კლასტერზე), რომელსაც ქსელის საშუალებით უკავშირდება ერთი ან მეტი აპლიკაციის სერვერი, რომელსაც, თავის მხრივ, ტერმინალები დაკავშირებულია ქსელის საშუალებით.

უპირატესობები

კლიენტ-სერვერთან შედარებით ან ფაილის სერვერის არქიტექტურასამი დონის არქიტექტურის შემდეგი უპირატესობები შეიძლება გამოვლინდეს:

· მასშტაბურობა

· კონფიგურაცია - დონეების ერთმანეთისგან იზოლაცია საშუალებას იძლევა (არქიტექტურის სათანადო განლაგებით) სწრაფად და მარტივი საშუალებებითსისტემის ხელახლა კონფიგურაცია, როდესაც ხდება მარცხი ან დაგეგმილი შენარჩუნების დროს ერთ-ერთ დონეზე

· მაღალი უსაფრთხოება

· მაღალი საიმედოობა

· დაბალი მოთხოვნებიტერმინალებსა და აპლიკაციის სერვერს შორის არხის (ქსელის) სიჩქარეზე

დაბალი შესრულების მოთხოვნები და ტექნიკური მახასიათებლებიტერმინალები, რის შედეგადაც მცირდება მათი ღირებულება. ტერმინალი შეიძლება იყოს არა მხოლოდ კომპიუტერი, არამედ, მაგალითად, მობილური ტელეფონი.

ხარვეზები

უარყოფითი მხარეები მოჰყვება უპირატესობებს. კლიენტ-სერვერთან ან ფაილ-სერვერის არქიტექტურასთან შედარებით, სამსაფეხურიანი არქიტექტურის შემდეგი უარყოფითი მხარეები შეიძლება გამოვლინდეს:

· აპლიკაციების შექმნის უფრო მაღალი სირთულე;

· უფრო რთული განლაგება და ადმინისტრირება;

· მაღალი მოთხოვნებიაპლიკაციის სერვერებისა და მონაცემთა ბაზის სერვერის მუშაობაზე და, შესაბამისად, მაღალი ფასისერვერის აღჭურვილობა;

· მაღალი მოთხოვნები არხის (ქსელის) სიჩქარეზე მონაცემთა ბაზის სერვერსა და აპლიკაციის სერვერებს შორის.

თარგმანი ინგლისურიდან: ჩერნობაი ა.

კლიენტ-სერვერის სისტემების განვითარება

არქიტექტურა კომპიუტერული სისტემაგანვითარდა ტექნიკის უნართან ერთად გამოიყენოს აპლიკაციები, რომლებსაც ის აწარმოებს. უმარტივესი (და ყველაზე ადრეული) იყო "მთავარი არქიტექტურა", რომელშიც ყველა ოპერაცია და ფუნქციონირება ხორციელდება სერვერის (ან "მასპინძლის") კომპიუტერის შიგნით. მომხმარებლები ურთიერთობდნენ სერვერთან „მუნჯი“ ტერმინალების საშუალებით, რომლებიც კლავიშების დაჭერით გადასცემდნენ ინსტრუქციებს სერვერზე და აჩვენებდნენ ინსტრუქციების შედეგებს მომხმარებელს. ასეთი აპლიკაციები იყო ტიპიური და, მიუხედავად შედარებით დიდი გამოთვლითი სიმძლავრისა სერვერის კომპიუტერები, ძირითადად შედარებით ნელი და უხერხული იყო გამოსაყენებლად, თითოეული კლავიშის სერვერზე გადაცემის საჭიროების გამო.

კომპიუტერის დანერგვა და ფართო გამოყენება, საკუთარი გამოთვლითი ძალადა გრაფიკული მომხმარებლის ინტერფეისი საშუალებას აძლევდა აპლიკაციებს გამხდარიყო უფრო რთული და გაფართოებული ქსელური სისტემებიგამოიწვია სისტემის არქიტექტურის მეორე ძირითადი ტიპი, "ფაილის დაყოფა". ამ კომპიუტერის არქიტექტურაში (ან " სამუშაო სადგური") ჩამოტვირთავს ფაილებს სპეციალიზებული "ფაილ სერვერიდან" და შემდეგ მართავს აპლიკაციას (მონაცემების ჩათვლით) ლოკალურად. ეს კარგად მუშაობს, როდესაც მონაცემთა საერთო გამოყენება, მონაცემთა განახლებები და გადასაცემი მონაცემების რაოდენობა მცირეა. თუმცა, მალე გახდა ნათელია, რომ ფაილების გაზიარება უფრო მეტად ბლოკავს ქსელს და აპლიკაციები უფრო რთული გახდა და ყველას ესაჭიროება დიდი რაოდენობითმონაცემები გადაიტანეს ორივე მიმართულებით.

ქსელში გაზიარებულ ფაილზე მონაცემთა დამუშავების აპლიკაციებთან დაკავშირებულმა პრობლემებმა განაპირობა კლიენტ-სერვერის არქიტექტურის განვითარება 1980-იანი წლების დასაწყისში. ამ მიდგომით, ფაილების სერვერი იცვლება მონაცემთა ბაზის სერვერით, რომელიც, ვიდრე უბრალოდ გადასცემს და ინახავს ფაილებს დაკავშირებულ სამუშაო სადგურებზე (კლიენტებს), იღებს და რეალურად ახორციელებს მონაცემთა მოთხოვნას, აბრუნებს მხოლოდ კლიენტის მიერ მოთხოვნილ შედეგს. მხოლოდ კლიენტის მიერ მოთხოვნილი მონაცემების გადაცემით და არა მთელი ფაილის, ეს არქიტექტურა მნიშვნელოვნად ამცირებს ქსელის დატვირთვას. ამან შესაძლებელი გახადა სისტემის შექმნა, რომელშიც მრავალ მომხმარებელს შეეძლო მონაცემთა განახლება GUI ინტერფეისების მეშვეობით, რომლებიც დაკავშირებულია ერთ გაზიარებულ მონაცემთა ბაზასთან.

როგორც წესი, სტრუქტურირებული შეკითხვის ენა (SQL) ან დისტანციური პროცედურის გამოძახება (RPC) გამოიყენება კლიენტსა და სერვერს შორის მონაცემთა გაცვლისთვის. კლიენტ-სერვერის არქიტექტურის ორგანიზების რამდენიმე ძირითადი ვარიანტი აღწერილია ქვემოთ.

ორსაფეხურიან არქიტექტურაში, დატვირთვა იზიარებს სერვერს (რომელიც შეიცავს მონაცემთა ბაზას) და კლიენტს (რომელიც შეიცავს მომხმარებლის ინტერფეისს). როგორც წესი, ისინი განლაგებულია სხვადასხვა ფიზიკური მანქანებიმაგრამ ეს არ არის სავალდებულო მოთხოვნა. იმ პირობით, რომ ფენები ლოგიკურად გამოყოფილია, მათი განთავსება შესაძლებელია (მაგალითად, განვითარებისა და ტესტირებისთვის) იმავე კომპიუტერზე (ნახ. 1).

სურათი 1: ორსაფეხურიანი არქიტექტურა

ამ მოდელში განაცხადის ლოგიკისა და მონაცემთა დამუშავების განაწილება იყო და რჩება პრობლემატური. თუ კლიენტი არის "ჭკვიანი" და ახორციელებს მონაცემთა ძირითად დამუშავებას, მაშინ პრობლემები წარმოიქმნება აპლიკაციის განაწილებასთან, ინსტალაციასთან და შენარჩუნებასთან, რადგან თითოეულ კლიენტს სჭირდება საკუთარი ადგილობრივი ასლიპროგრამული უზრუნველყოფა. თუ კლიენტი "დუმდა" აპლიკაციის ლოგიკა და დამუშავება უნდა განხორციელდეს მონაცემთა ბაზაში და, შესაბამისად, იგი მთლიანად დამოკიდებული ხდება კონკრეტულ DBMS-ზე, რომელიც გამოიყენება. ნებისმიერ შემთხვევაში, თითოეულმა კლიენტმა უნდა დარეგისტრირდეს და, მიღებული წვდომის უფლებებიდან გამომდინარე, შეასრულოს გარკვეული ფუნქციები. თუმცა, ორსაფეხურიანი კლიენტ-სერვერის არქიტექტურა იყო კარგი გადაწყვეტილება, როდესაც მომხმარებელთა რაოდენობა შედარებით მცირე იყო (დაახლოებით 100-მდე ერთდროულად მომხმარებელი), მაგრამ მომხმარებელთა ზრდასთან ერთად მოვიდა მთელი რიგი შეზღუდვები ამ არქიტექტურის გამოყენებაზე.

შესრულება: მომხმარებელთა რაოდენობის მატებასთან ერთად, შესრულება იწყებს გაუარესებას. შესრულების დეგრადაცია პირდაპირპროპორციულია მომხმარებელთა რაოდენობისა, რომელთაგან თითოეულს ჰყავს საკუთარი კავშირისერვერზე, რაც ნიშნავს, რომ სერვერმა უნდა შეინარჩუნოს ყველა ეს კავშირი ("Keep-Alive" შეტყობინების გამოყენებით), მაშინაც კი, როდესაც მონაცემთა ბაზაზე წვდომა არ არის.

უსაფრთხოება: თითოეულ მომხმარებელს უნდა ჰქონდეს საკუთარი ინდივიდუალური წვდომამონაცემთა ბაზაში და აქვს აპლიკაციის ფუნქციონირების უფლება. ამისათვის საჭიროა მონაცემთა ბაზაში თითოეული მომხმარებლის წვდომის უფლებების შენახვა. როდესაც გჭირდებათ ფუნქციების დამატება აპლიკაციაში და გჭირდებათ მომხმარებლის უფლებების განახლება.

ფუნქციონალობა: არ აქვს მნიშვნელობა რა ტიპის კლიენტი გამოიყენება, უმეტესობამონაცემთა დამუშავება უნდა იყოს მონაცემთა ბაზაში, რაც ნიშნავს, რომ ის მთლიანად დამოკიდებულია მწარმოებლის მიერ მონაცემთა ბაზაში მოწოდებულ შესაძლებლობებზე. ამან შეიძლება სერიოზულად შეზღუდოს აპლიკაციის ფუნქციონირება, რადგან სხვადასხვა ბაზებიმონაცემები მხარს უჭერს სხვადასხვა ფუნქციებს, გამოყენება სხვადასხვა ენებზეპროგრამირება და თუნდაც ძირითადი ფუნქციების დანერგვა, როგორიცაა ტრიგერები სხვადასხვა გზით.

პორტაბელურობა: ორსაფეხურიანი არქიტექტურა იმდენად არის დამოკიდებული მონაცემთა ბაზის კონკრეტულ განხორციელებაზე, რომ პორტაბელურობა არსებული აპლიკაციებისხვადასხვა DBMS-ისთვის სერიოზულ პრობლემად იქცევა. ეს განსაკუთრებით ეხება ვერტიკალურ ბაზრებზე არსებულ აპლიკაციებს, სადაც DBMS-ის არჩევანი არ არის განსაზღვრული გამყიდველის მიერ.

მაგრამ ამის მიუხედავად, ნაპოვნი იქნა ორ დონის არქიტექტურა ახალი ცხოვრებაინტერნეტის ეპოქაში. მას შეუძლია კარგად იმუშაოს გათიშულ მდგომარეობაში გარემო, სადაც UI არის „მუნჯი“ (მაგ. ბრაუზერი). თუმცა, მრავალი თვალსაზრისით, ეს იმპლემენტაცია წარმოადგენს დაბრუნებას თავდაპირველ მთავარ არქიტექტურაში.

აღწერილი ორსაფეხურიანი არქიტექტურის შეზღუდვების გადალახვის მცდელობისას ზოგადი მონახაზიზემოთ დაინერგა დამატებითი დონე. ეს არქიტექტურა არის სტანდარტული მოდელიკლიენტ-სერვერი სამსაფეხურიანი არქიტექტურით. დამატებითი ფენის (რომელსაც ჩვეულებრივ უწოდებენ "შუა" ან "წესებს" ფენას) დანიშნულებაა აპლიკაციის შესრულების და მონაცემთა ბაზის მენეჯმენტის მართვა. როგორც ორდონიანი მოდელის შემთხვევაში, დონეები შეიძლება განთავსდეს ორივეზე სხვადასხვა კომპიუტერები(სურათი 2), ან ერთ კომპიუტერზე ტესტის რეჟიმში.

სურათი 2: სამსაფეხურიანი არქიტექტურა

შუა რიგის შემოღებით, ორსაფეხურიანი არქიტექტურის შეზღუდვები დიდწილად აღმოიფხვრა, რის შედეგადაც შეიქმნა ბევრად უფრო მოქნილი და მასშტაბური სისტემა. ვინაიდან კლიენტები ახლა უკავშირდებიან მხოლოდ აპლიკაციის სერვერს და არა უშუალოდ მონაცემთა სერვერს, კავშირების შენარჩუნების ტვირთი მოხსნილია, ისევე როგორც აპლიკაციის ლოგიკის დანერგვის აუცილებლობა მონაცემთა ბაზაში. მონაცემთა ბაზას ახლა შეუძლია შეასრულოს მხოლოდ მონაცემების შენახვისა და მოპოვების ფუნქციები, ხოლო აპლიკაციების მიღებისა და დამუშავების ამოცანა შეიძლება შესრულდეს საშუალო დონე სამსაფეხურიანი არქიტექტურა. განვითარება ოპერატიული სისტემა, რომელიც მოიცავს ისეთ ელემენტებს, როგორიცაა კავშირის გაერთიანება, რიგები და დამუშავება განაწილებული ტრანზაქციებიგაძლიერებული (და გამარტივებული) საშუალო დონის განვითარება.

გაითვალისწინეთ, რომ ამ მოდელში აპლიკაციის სერვერი არ აკონტროლებს მომხმარებლის ინტერფეისს და არც მომხმარებელი რეალურად კითხულობს მონაცემთა ბაზას. ამის ნაცვლად, ის საშუალებას აძლევს მრავალ კლიენტს გაუზიარონ ბიზნეს ლოგიკა, გამოთვლები და წვდომა საძიებო სისტემამონაცემები. მთავარი უპირატესობა ის არის, რომ კლიენტს ნაკლები პროგრამული უზრუნველყოფა სჭირდება და აღარ სჭირდება პირდაპირი კავშირიმონაცემთა ბაზაში, რაც ზრდის უსაფრთხოებას. შესაბამისად, აპლიკაცია უფრო მასშტაბურია, ერთ სერვერზე მხარდაჭერისა და ინსტალაციის ხარჯები გაცილებით დაბალია, ვიდრე აპლიკაციების უშუალოდ კლიენტის კომპიუტერზე ან თუნდაც ორსაფეხურიან არქიტექტურაზე.

არსებობს ძირითადი სამ დონის მოდელების მრავალი ვარიაცია, რომელიც შექმნილია შესასრულებლად სხვადასხვა ფუნქციები. ეს მოიცავს განაწილებულ ტრანზაქციის დამუშავებას (სადაც მრავალი DBMS განახლებულია იმავე პროტოკოლში), შეტყობინებებზე დაფუძნებულ აპლიკაციებს (სადაც აპლიკაციები რეალურ დროში არ ურთიერთობენ) და პლატფორმის თავსებადობას (ობიექტი). მოითხოვეთ ბროკერიან "ORB" აპლიკაცია).

მრავალსაფეხურიანი არქიტექტურა ან N- დონის არქიტექტურა

ინტერნეტ აპლიკაციების შემუშავებით მომხმარებელთა რაოდენობის ზოგადი ზრდის ფონზე, მთავარი სამ დონის კლიენტ-სერვერის მოდელიგაფართოვდა დამატებითი დონეების შემოღებით. ასეთ არქიტექტურებს უწოდებენ "მრავალსაფეხურიანი" და, როგორც წესი, შედგება ოთხი ფენისგან (სურათი 3), სადაც სერვერი პასუხისმგებელია ბრაუზერის კლიენტსა და აპლიკაციის სერვერს შორის კავშირის მართვაზე ერთი აპლიკაციის სერვერზე, რითაც იზრდება დამუშავება მეტიერთდროულად დაკავშირებული მომხმარებლები.

სურათი 3: N- დონის არქიტექტურა

დონეები ფენების წინააღმდეგ

ეს ტერმინები (სამწუხაროდ) ხშირად არის დაბნეული. თუმცა მათ შორის დიდი განსხვავებადა აქვს გარკვეული მნიშვნელობა. მთავარი განსხვავება ისაა, რომ დონეებია ფიზიკური დონე, და ფენები ლოგიკურად არის. სხვა სიტყვებით რომ ვთქვათ, დონე, თეორიულად, შეიძლება დამოუკიდებლად განლაგდეს ცალკე კომპიუტერიდა ფენა ლოგიკური განცალკევებადონის შიგნით (სურათი 4). Ტიპიური სამ დონის მოდელიზემოთ აღწერილი, როგორც წესი, შეიცავს მინიმუმ შვიდ ფენას, გამოყოფილი სამივე დონეზე.

მთავარი, რაც უნდა გვახსოვდეს ფენიანი არქიტექტურის შესახებ, არის ის, რომ მოთხოვნები და პასუხები თითოეული ძაფიდან ერთი მიმართულებით გადის ყველა ფენას და რომ ფენების გამოტოვება შეუძლებელია. ამრიგად, 4-ზე ნაჩვენები მოდელში, ერთადერთი ფენა, რომელსაც შეუძლია წვდომა ფენაზე "E" (მონაცემებზე წვდომის ფენა) არის ფენა "D" (წესების ფენა). ანალოგიურად, ფენას "C" (აპლიკაციის ვალიდაციის ფენა) შეუძლია უპასუხოს მხოლოდ ფენის "B" (შეცდომის დამუშავების ფენა) მოთხოვნებს.

სურათი 4: რიგები დაყოფილი ლოგიკურ შრეებად