Дәріс Клиент-серверлік жүйелерге кіріспе
жүктеу/скачать 110,67 Kb.
|
Лекциялар жиыны Web қосымшаларды әзірлеу
| Проблеманың шешімі
Недостатки архитектуры Клиент-сервер архитектураларының кемшіліктері анықталды, ал оның шешімі шынымен-ақ бетінде жатыр. Бизнес-логиканы серверден және клиенттен бөлек, орталық бөлімге шоғырлау қажет. Сонымен қатар ішкіжүйелердің әрекеттесуінің стандартты протоколы болуы керек, олар әр түрлі бағдарламалау тілінде жазылуы және көптеген аппараттық платформада жұмыс істеуі мүмкін. Жоғарыда көрсетілген әдісті жүзеге асыру кезінде, 1.2 - суретте бейнеленген архитектураны аламыз. Бұл жағдайда тек бизнес-функционалдық қана емес, сонымен қатар деректер базасының серверіне кіру механизмі бір орында - қосымшалар серверінде (Application Server)орналастырылған. Және де бизнес – логикасы бар бірнеше серверлер болуына ештеңе кедергі келтірмейді, бұл жағдай сақтау үшін де, жүктеу балансы үшін де қолданылуы мүмкін. Администраторлар уақыт тәртібіндегі жұмыстарын, жүйенің «тұруынан» қорықпай-ақ оңай өндіре алады. Бизнес – логиканың жаңаруы қосымша серверде жасалады, бұл тек қолайлы ғана емес, сонымен бірге үнемді. Версиялық механизмін қолдану барысында, бұл операцияны жүйе жұмыс істеп тұрған кезде өндіруге болады. Шамасы, мұндай архитектурада әр түрлі SQL-серверлерді қосымша серверлер үшін деректер көзі ретінде қолдану өте ыңғайлы. Клиенттік жақта не жұмыс істейтінін қарастырайық. 1.2 – сурет - Үшдеңгейлі клиент-сервер архитектурасы Мұнда тек бизнес - логикамен жұмыс істеу шешімдерін көзбен шолу коды ғана қалады, қолданылып отырған бизнес – логиканың өкілдері (proxies) мен транспорттық объектілік қарым – қатынас модулі (connectivity). Сәйкесінше, клиенттік машиналарға аппараттық талапты төмендетеді. ДБ-на кіру механизмінің «жұқа» конфигурациясы қосымша серверде құрылатындықтан, жүйені өрістету және қолдауға шығын азаяды. Ал клиенттік орындар мен қосымша серверлерді құру үшін Java технологиясын қолданған кезде, администраторлар бір орында отырып-ақ барлық клиенттік орындарды және серверлерді автоматты түрде жаңартуды жүргізе алады. Деректер базасының сервері туралы айтатын болсақ, ол жиі өте үлкен көлемді триггерлерді немесе сақтау процедураларын орындауға қатты «алаңдамайды». Ол өзі бәрінен жақсы істей алатын жұмысын жасайды – сақтайды және деректердің тұтастығын қамтамасыз етеді. Бұл оның өнімділігіне жақсы әсер етеді; серверлер үлкен көлемді деректерді сол баяғы «темірде» тез өңдей алады. Кез келген кәсіпорынды басқару жүйесінде біз ең аз дегенде екі түрлі пайдаланушыны көре аламыз: көбінесе уақыт бойынша ұзаққа созылатын транзакциямен жұмыс жасайтын аналитиктерді және қысқа түрдегі транзакциямен жұмыс жасайтын пайдаланушыларды. Егер үшдеңгейлі архитектураны қолдану кезінде әртүрлі қосымша серверлердегі аналитиктер және операционисттерге арналған бизнес – логиканы тарату дұрыс шешім болып табылады. Сол арқылы жалпы жүйенің сенімділігі және оның жылдамдықтық мінездемесі жоғарылайды. Тіпті ең қарапайым тесттер көптізбекті жүйенің реакция жылдамдығы пайдаланушының көзқарасы бойынша 1,5-2,5 есе жоғары екенін дәлелдейді, ал бірнеше қосымша серверлер бойынша тиеу балансын қолданған кезде, мұндай жүйе бір мезгілде жұмыс істеп тұрған мың пайдалаушыға қызмет көрсете алады. Қолданбалы архитектура бойынша, жүйенің компоненттілігінің жоғары көрсеткішін бизнес – логика деңгейінде аламыз – демек, жүйенің функционалдығын қайта қолдану жеңілдетіледі. ДБ-ның серверінің және қосымша сервердің транспорттық қарым – қатынасы классикалық клиент – сервер кезіндегідей. Мұнда бәрі түсінікті, бірақ қосымша сервер жағында клиенттік қосымшаның бизнес – объектілермен қарым – қатынасын қалай қамтамасыз ету керек деген сұрақ туындайды. Желілік инфрақұрылымдағы функционалдық компоненттердің қарым – қатынасының барлық қиындықтарын қысқартуға арналған программалық қамтамасыз ету middleware – ортаңғы тізбекті қамтамасыз ету деп аталады. Қазіргі кезде нарықта кездесетін middleware таралған есептердің үш технологиясы бар: - DCE (Distributed Computing Environment) технологиясы OSF (Open Software Foundation, www.osf.org) консорциумынан - CORBA (Common Object Request Broker Architecture) архитектурасы OMG (Object Management Group, www.omg.org) консорциумынан, IBM-ның 900-ден аса тұрақты мүшелері, Inprise, Oracle, Sun, Hitachi). жүктеу/скачать 110,67 Kb. Достарыңызбен бөлісу:
|