Coulouris-მა განსაზღვრა განაწილებული სისტემები, როგორც „სისტემები, რომლებშიც კომპიუტერულ ქსელში არსებული აპარატურა და/ან პროგრამული კომპონენტები ურთიერთობენ და კოორდინირებენ თავიანთ მოქმედებებს შეტყობინებების გაცვლით“.
ეს კონცეფცია პოპულარული გახდა ბოლო წლებში რამდენიმე ფაქტორის გამო. პირველი ფაქტორი, რომელმაც ხელი შეუწყო განაწილებული სისტემების განვითარებას, იყო მაღალსიჩქარიანი ლოკალური ქსელების გაჩენა. კიდევ ერთი მნიშვნელოვანი ფაქტორი იყო ტექნოლოგიური წინსვლა პერსონალური კომპიუტერების მუშაობაში და პროგრამული უზრუნველყოფის შემუშავება განაწილებული აპლიკაციების მხარდასაჭერად. განაწილებული სისტემები დაკავშირებულია ვებსა და ინტერნეტის კონცეფციასთან. ვებ-გვერდის ევოლუციასთან და ახალი სფეროების, ურთიერთქმედებების, საჭიროებებისა და აპლიკაციების გამოჩენასთან ერთად ჩნდება Web 2.0 კონცეფცია. ეს ტერმინი გამოიგონა ტიმ ო'რეილიმ 2004 წელს, რათა მიუთითებდეს ინტერნეტის ისტორიაში მეორე თაობაზე, რომელიც დაფუძნებულია მომხმარებელთა საზოგადოებებზე და სერვისების სპეციალურ სპექტრზე, როგორიცაა სოციალური ქსელები, ბლოგები, ვიკიები ან ფოლკლსონომიები, რომლებიც ხელს უწყობენ თანამშრომლობას და სწრაფ მუშაობას. ინფორმაციის გაცვლა მომხმარებლებს შორის.
პირველი არქიტექტურები, რომლებიც შეიძლება ჩაითვალოს სერვისზე ორიენტირებულად (SOA) დაფუძნებული იყო CORBA-ზე (Common Object Request Broker Architecture), რომელიც მოქმედებდა როგორც აბსტრაქციული ფენა არქიტექტურის სხვადასხვა ელემენტების ერთმანეთთან დასაკავშირებლად და სერვისების შესაქმნელად. სხვა ადრინდელი ტექნოლოგიები იყო DCOM (განაწილებული კომპონენტის ობიექტის მოდელი) ან RPC (დისტანციური პროცედურის პროტოკოლი). ინტერნეტში განაწილებული სისტემების ეფექტური დიზაინისა და დანერგვის აუცილებლობის გამო, წარმოიქმნება რამდენიმე გამოწვევა, ზოგი ფოკუსირებულია თავად განვითარებაზე (შესრულება, მომხმარებლის გამოცდილება და ა.შ.) და სხვა დამატებითი გამოწვევები, რომლებიც დაფუძნებულია სერვისების ხელახლა გამოყენებასა და თავსებადობაზე. ამ მოთხოვნილებებიდან წარმოიქმნება ვებ სერვისები, რომლებიც უზრუნველყოფენ სტანდარტიზებულ მექანიზმებს სხვადასხვა მომხმარებლის საინფორმაციო სერვერებთან დასაკავშირებლად.
სერვისზე ორიენტირებული არქიტექტურა
SOA-ს მიხედვით (სერვისზე ორიენტირებული არქიტექტურა) არის პროგრამული არქიტექტურა, რომელიც განსაზღვრავს სერვისების გამოყენებას ბიზნესის მოთხოვნების მხარდასაჭერად, რომლის მიზანია მიაღწიოს პროგრამულ აგენტებს შორის მინიმუმ შესაძლო დაწყვილებას. სერვისი არის სამუშაოს ერთეული, რომელსაც ასრულებს სერვისის მიმწოდებელი მომსახურების მომხმარებლისთვის სასურველი საბოლოო შედეგის მისაღწევად. როგორც სერვისის მიმწოდებელი, ასევე სერვისის მომხმარებელი არის პროგრამული უზრუნველყოფის აგენტების როლები და არა პროგრამული უზრუნველყოფის მფლობელები. ზოგადი გაგებით, სერვისზე ორიენტირებული არქიტექტურა არის პროგრამული გადაწყვეტა, რომელიც მიზნად ისახავს საწარმოს ორგანიზებას და სხვადასხვა პროცესების გამოყენებას. SOA-სთან ერთად, პროგრამული აპლიკაციები აღარ არის ფუნქციების და პროცესების მასიური ბლოკები. ამის ნაცვლად, ეს აპლიკაციები შედგება აწყობილი მოდულური სერვისებისგან. გახსოვდეთ, რომ სერვისი არის მარტივი პროგრამული ფუნქცია (როგორიცაა CD-ის გაუქმება). მისი მოთხოვნით გაშვება შესაძლებელია ნებისმიერი სისტემის მიერ, ოპერაციული სისტემის, პლატფორმის, პროგრამირების ენისა თუ გეოგრაფიული მდებარეობის მიუხედავად.
SOA-ში რევოლუციურია არა თავად კონცეფცია, რომელიც უკვე დიდი ხანია არსებობს, არამედ ის, რომ მისი დანერგვა შესაძლებელია WWW-ზე (მსოფლიო ქსელი). ისევე, როგორც ვებ გვერდები იტვირთება ნებისმიერ პლატფორმაზე, ვებ სერვისები ანალოგიურად მუშაობს, მიუხედავად პლატფორმისა, რადგან ისინი აგებულია გამოყენებით
უნივერსალური სტანდარტები.
SOA-ს იდეა პირდაპირ სათავეს იღებს ობიექტზე ორიენტირებული პროგრამირებიდან, რაც მიუთითებს მონაცემებსა და მის დამუშავებას შორის ურთიერთობაზე. ამრიგად, ისინი ოფიციალურად განსაზღვრავენ სერვისებს ინტერფეისების საშუალებით, რომლებიც დამოუკიდებელია ძირითადი პლატფორმისა და პროგრამირების ენისგან. ეს ინტერფეისები მალავს მათი განხორციელების თავისებურებებს, რაც მათ დამოუკიდებელ ხდის დეველოპერი და პროგრამირების ენა. ამ არქიტექტურის საშუალებით შესაძლებელია მაღალი მასშტაბირებადი სისტემების დაპროექტება და დანერგვა, რომლებიც ასახავს ბიზნეს ლოგიკას და ამავდროულად ხელს უწყობს სხვადასხვა საკუთრების ან მესამე მხარის სისტემებს შორის ურთიერთქმედებას. მიზეზი, რის გამოც ჩვენ გვინდა, რომ სხვამ გააკეთოს სამუშაო ჩვენთვის არის ის, რომ ისინი ექსპერტები არიან. სერვისით სარგებლობა ჩვეულებრივ უფრო იაფი და ეფექტურია, ვიდრე საკუთარი თავის გაკეთება. ასე რომ, უმეტეს ჩვენგანს ესმის, რომ ჩვენ არ შეგვიძლია ვიყოთ ექსპერტები ყველაფერში. იგივე წესი შეიძლება გამოყენებულ იქნას პროგრამული სისტემების მშენებლობაზე.
ინტერფეისები ძალიან მნიშვნელოვანია, თუ ისინი კარგად არ არის განსაზღვრული ან არ მუშაობს, სისტემა არ მუშაობს. მეტი ინტერფეისის ინტეგრირება ძვირია და ასევე ზრდის შეცდომების პოტენციალს განაწილებულ აპლიკაციებში. დისტანციური ინტერფეისები ყველაზე განაწილებული აპლიკაციების ყველაზე ნელი ნაწილია. ამ ყველაფერთან ერთად, ყოველი აპლიკაციისთვის ახალი ინტერფეისების შექმნის ნაცვლად, უფრო აზრიანია ზოგადი ინტერფეისების ხელახლა გამოყენება ყველა აპლიკაციისთვის.
ასე რომ, რადგან ჩვენ გვაქვს მხოლოდ რამდენიმე ზოგადი ინტერფეისი ხელმისაწვდომი, ჩვენ უნდა შევიტანოთ აპლიკაციის სპეციფიკური სემანტიკა შეტყობინებებში. ჩვენ შეგვიძლია გავაგზავნოთ ნებისმიერი სახის შეტყობინება ჩვენი ინტერფეისის საშუალებით, მაგრამ არსებობს გარკვეული წესები, რომლებიც უნდა დავიცვათ, რომ ვთქვათ, რომ არქიტექტურა არის სერვისზე ორიენტირებული.
– პირველ რიგში, შეტყობინებები უნდა იყოს აღწერითი და არა სასწავლო, რადგან პრობლემის გადაჭრაზე პასუხისმგებელია სერვისის პროვაიდერი. მაგალითად, მსგავსი იქნება რესტორანში წასვლა და ოფიციანტს ეუბნები, რისი დალევა და შენი პრეფერენციები გინდა, მაგრამ მზარეულს ეტაპობრივად არ უნდა ავუხსნათ როგორ მოამზადოს კერძები.
‐ მეორე, სერვისის პროვაიდერები ვერ გაიგებენ თქვენს მოთხოვნას, თუ მათი შეტყობინებები არ არის დაწერილი ფორმატით, სტრუქტურით და ლექსიკური მარაგით, რომელიც გასაგები იქნება ყველა მონაწილესთვის. ამრიგად, შეტყობინებების ლექსიკისა და სტრუქტურის შეზღუდვა არის ა
აუცილებელია ეფექტური კომუნიკაციისთვის. რაც უფრო ვიწროა შეტყობინება, მით უფრო ადვილი გასაგებია.
- მესამე, გაფართოების შესაძლებლობა სასიცოცხლოდ მნიშვნელოვანია. სამყარო მუდმივად ცვალებადი ადგილია, ისევე როგორც გარემო, რომელშიც პროგრამული უზრუნველყოფა ცხოვრობს. ეს ცვლილებები მოითხოვს შესაბამის ცვლილებებს სისტემის პროგრამულ უზრუნველყოფაში, მომხმარებლებში სერვისების, პროვაიდერების და მათ მიერ გაცვლილი შეტყობინებების შესახებ. თუ შეტყობინებები არ არის გაფართოებული, მომხმარებლები და პროვაიდერები დაბლოკილია სერვისის კონკრეტულ ვერსიაზე. შეზღუდვა და გაფართოება ღრმად არის დაკავშირებული, თქვენ გჭირდებათ ორივე და ერთის გაზრდა ნიშნავს მეორის შემცირებას. იდეალურია სწორი ბალანსის მიღწევა.
– მეოთხე, SOA-ს უნდა ჰქონდეს მექანიზმი, რომელიც მომხმარებელს საშუალებას აძლევს აღმოაჩინოს მომსახურების მიმწოდებელი მომხმარებლის მიერ მოთხოვნილი სერვისის კონტექსტში. მექანიზმი უნდა იყოს მოქნილი და არა ცენტრალიზებული რეესტრი.
- მეხუთე, მოქალაქეობის არმქონე სერვისი: თითოეული შეტყობინება, რომელსაც მომხმარებელი უგზავნის პროვაიდერს, უნდა შეიცავდეს ყველა ინფორმაციას, რომელიც აუცილებელია პროვაიდერისთვის მისი დამუშავებისთვის. ეს შეზღუდვა სერვისის პროვაიდერს უფრო მასშტაბურს ხდის, რადგან პროვაიდერს არ სჭირდება სახელმწიფო ინფორმაციის შენახვა მოთხოვნებს შორის. ამას შეიძლება ეწოდოს "მასობრივი წარმოების სერვისი", რადგან თითოეული მოთხოვნა შეიძლება განიხილებოდეს ზოგადი გზით. ეს შეზღუდვა ასევე უზრუნველყოფს მეტ ხილვადობას, რადგან მონიტორინგის ნებისმიერ პროგრამას შეუძლია დამოუკიდებლად შეამოწმოს მოთხოვნა და ამოიღოს მისი განზრახვა. ეს ასევე საშუალებას იძლევა ადვილად აღდგეს ნაწილობრივი წარუმატებლობისგან, რადგან არ არსებობს შუალედური მდგომარეობა, რაც სერვისს უფრო საიმედოს ხდის.
- მეექვსე, იდემპოტენტური მოთხოვნები (ცვლილებების გარეშე): პროგრამული აგენტის მიერ მიღებულ დუბლიკატულ მოთხოვნას აქვს იგივე ეფექტი, რაც ერთ მოთხოვნას. ეს მოთხოვნა პროვაიდერებსა და მომხმარებლებს საშუალებას აძლევს გაზარდონ მთლიანი სანდოობა მომსახურება, უბრალოდ გაიმეორეთ მოთხოვნა, თუ რაიმე მარცხი იყო.
ასე რომ, შეგვიძლია ვთქვათ, რომ SOA არ არის ინსტრუმენტი, არამედ სტანდარტების ნაკრები ახალი აპლიკაციების შესაქმნელად, უფრო დინამიური და ნაკლებად დამოკიდებული. SOA აადვილებს ბიზნეს ლოგიკასა და ინფორმაციაზე წვდომას მრავალ სერვისზე სისტემატური გზით და ასევე შეუძლია მრავალი დისტანციური სერვისის ორკესტრირება ერთის შესაქმნელად. უმეტესობა განმარტებები განსაზღვრავს ვებ სერვისების გამოყენებას, რასაც შემდეგ თავში ვიხილავთ, სერვისზე ორიენტირებული არქიტექტურის განხორციელებაში. თუმცა, ის შეიძლება განხორციელდეს ნებისმიერი სხვა სერვისზე დაფუძნებული ტექნოლოგიის გამოყენებით.