Bu mövzuda mən açıq şəkildə servletlər haqqında anlayışım, servlet konteynerlərinin nə olduğu, ən çox, hətta hamısı olmasa da, veb front-end çərçivələrinin nə olduğu haqqında danışmaq, həmçinin servlet konteynerləri və tətbiq serverlərinin necə əlaqəli olduğu mövzusuna toxunmaq istərdim. bir-biri və servlet və veb server konteynerləri. Söhbətə başlamazdan əvvəl qeyd etmək istəyirəm ki, həqiqətən də müzakirə olacağını gözləyirəm, çünki... Burada mən bir kod parçası vermək istəmirəm, sadəcə olaraq hər zaman sözlə ifadə oluna bilən mahiyyətə toxunmaq istəyirəm. İlk başladığım zaman mənə aydın olmayan bütün bu məqamları qeyd etməyə çalışacağam. Müxtəlif forumlarda Tomcat servlet konteynerinin istənilən proqram serverindən, məsələn, WebSphere və ya Geronimo-dan nə ilə fərqləndiyi mövzusunda suallar verəndə cavab verməyə cəsarət edən yeganə insanlar “Vikipediyaya baxın” və ya “başqa heç nə deyə bilməyən götlər idi. demək çətindir, server proqramları - bu, korporativ proqramlar üçün mürəkkəb bir infrastrukturdur, hansı ki..." blah blah blah. Mən belə insanlara dözə bilmirəm və yəqin ki, çoxunuz da dözmürsünüz. Biz tarixi ədalətsizliyi düzəldəcəyik. Get...
Servletlər
Kimin nə deməsindən asılı olmayaraq, servlet Java-da yazılmış veb səhifədir. Bəziləri səhv etdiyimi və servletin veb tətbiqi olduğunu və bu anlayışlar arasında fərq olduğunu söyləyəcək, lakin bu belə deyil. İndi heç bir fərq yoxdur və PHP-də yazılmış saytları etibarlı şəkildə veb proqramlar adlandırmaq olar. İndi bu tamamilə təbiidir, çünki... php tam OOP-u dəstəkləyir və Joomla kimi CMS-lər bundan fəal şəkildə istifadə edirlər. Kod səviyyəsində servlet nədir? Bu, yuxuya gedən və kiminsə GET və ya POST HTTP sorğuları vasitəsilə onlara daxil olub-olmadığını yoxlayan bir sıra metodlara malik sinifdir. Bunlar. Brauzerdə bəzi GET sorğusu yazdıq, servlet sinfinin müvafiq metodu onu qəbul edir və sonra HTML səhifəsi şəklində ona cavab yaradır. Servletin klassik mənasında, Sun tərəfindən nəzərdə tutulduğu kimi, bu səhifə <!DOCTYPE htm>> sətirindən başlayaraq </html> sətri ilə bitən sətir-sətir müştəriyə göndərilirdi. Beləliklə, Java-da adlı əsas servlet sinfi var Servlet. Bundan əlavə, bu əsas sinifdən miras qalan və bununla da onun funksionallığını genişləndirən bir sıra digər siniflər var. Servlet budur - başqa heç nə deyil. Bu, sadəcə olaraq serverdə icra edilən PHP kodunun Java analoqudur və müştəriyə yalnız veb-brauzerin sorğusuna veb səhifə şəklində cavab göndərilir. Hamısı.
Veb cəbhə çərçivələri
Altyazı mürəkkəbdir və adətən onlar sadəcə front-end framework və ya hətta web muszle yazırlar , lakin mən burada vurğulamaq qərarına gəldim ki, biz front-end çərçivələri haqqında danışarkən, veb-brauzer vasitəsilə Java ilə işləmək üçün GUI-dən danışırıq. Bunlar. burada yenə Java-dakı veb-saytlardan danışırıq, yəni. servletlər haqqında. Demək olar ki, hər hansı bir front-end çərçivə nədir, məsələn, Apache Struts. Bu, sadəcə olaraq, baza sinfini genişləndirən siniflər toplusudur Servlet. Daha heç nə. Bunlar. bu, eyni adi servlet yaratmaq üçün sadəcə fərqli bir yoldur. Sadəcə olaraq, bu çərçivənin tərtibatçıları (və ya başqa sözlə, bu texnologiyanın tərtibatçıları) hesab edirdilər ki, onların baza sinfinə Servletbəzi metodlarla əlavə edilməsi proqramçı üçün Sun/Oracle-dan klassik servletin cüzi funksionallığından daha əlverişli olacaqdır. var.
JSP səhifələri
Demək olar ki, dərhal Java servlet konsepsiyasını tərtib edənlərin ağlına başqa bir fikir gəldi. Vəzifəsi müştəriyə html səhifəsi göndərmək olan bir servlet yazdığımız üçün, bu html səhifəsini dərhal yazmaq daha düzgün ola bilər və Java-da bir növ məntiqə ehtiyacınız varsa, onu birbaşa daxil edin. html-ə. Əgər aydınlaşmırsa, o zaman bu ifadə kömək edə bilər: jsp səhifəsi php səhifəsinin analoqudur. Çətin? Sonra yenə izah edəcəm. PHP-də səhifə yazarkən nə edirik? Bizdə statik html var və PHP-də döngələr və şərtlər kimi hər hansı məntiqi daxil etməli olduğumuz zaman onu teqin gövdəsinə daxil edirik <?php … ?>. jsp ilə hər şey eynidir, yalnız məntiq təmiz Java-da yazılır, kodu tagın gövdəsinə daxil edilir <% … %>. Bir daha servlet anlayışına qayıdaq. Əslində, JSP səhifəsi bir servletdir, lakin bir qədər fərqli yazılmışdır. Adi servletdə biz bəzi məntiqi yerinə yetirən və onun nəticələrinə əsasən müştəri üçün HTML səhifəsi yaradan metod yazırıq. Sadəcə, bir müddət sonra servlet tərtibatçıları düşünməyə başladılar: əgər metodda praktiki olaraq heç bir məntiq yoxdursa və demək olar ki, yalnız html səhifəsinin formalaşması baş verirsə, onda dərhal html səhifəsini yazmaq daha asan olmazdımı? minimal Java əlavələri etmək üçün hansı kodu? Yaxşı, jsp səhifələri haqqında son bir şey. Belə bir səhifəyə ilk dəfə daxil olduqda, o, servletə yığılır və sonra icra edilir. Bu jsp səhifəsinə sonrakı sorğular daha sürətli olacaq, çünki o, artıq tərtib olunacaq və yalnız icra edilməlidir.
Servlet qabı
Beləliklə, bir servlet sinfi və ya JSP səhifəsi yazdıq. Sonra nə var? Onları veb-serverə, məsələn, apache-yə necə itələmək olar ki, o, onları istifadəçinin veb brauzerinə göndərə bilsin? Veb server yalnız html göndərə bilər və əgər səhifəmizdə, deyək ki, php kodu varsa, o zaman veb server əvvəlcə php-ni html-ə çevirən tərcüməçi vasitəsilə səhifəni keçirir və yalnız bundan sonra nəticə müştəriyə göndərilir. Təxminən eyni şey servletlərlə baş verir - göndərilməzdən əvvəl HTML səhifəsinin yaradılması üçün onları yerinə yetirmək lazımdır və servlet konteyneri məhz servletlərin və jsp səhifə kodunun icrasına cavabdeh olan şeydir. Bunlar. Java üçün servlet konteyneri veb serverdəki php tərcüməçi modulunun analoqudur. Beləliklə, istifadəçi veb-brauzerdə ünvanı daxil etdikdə sorğu veb serverə göndərilir, veb server servletin tələb olunduğunu başa düşür və sorğunu servlet konteynerinə ötürür. Bundan sonra servlet konteyneri servleti yerinə yetirir, nəticədə yaranan HTML səhifəsini veb serverə göndərir, bu da öz növbəsində onu müştəriyə qaytarır. Servlet konteyneri öz-özünə işləyə bilərmi, yəni. veb server olmadan? Tomcat kimi bir şey mütləq edə bilər. Servletlərə əsaslananlardan başqa heç bir başqa html səhifəsi olmayan sayt yaratmaq istəyiriksə, onda bir servlet konteyneri bizim üçün kifayət qədər kifayətdir. Ancaq servletlərdən və deyək ki, PHP səhifələrindən saytı birləşdirmək istəyiriksə, onda veb server quraşdırmalı olacağıq. Üstəlik, bütün veb serverlərdə standart olaraq servlet konteyneri yoxdur, lakin demək olar ki, hamısı onu plagin kimi quraşdırmağa imkan verir. Buna görə də, veb saytımızı Apache-nin çox güman ki, işlədiyi İnternetdəki bəzi hostinqdə işə salmaq istəsək, o zaman provayderdən servlet konteynerinin qoşulub-qoşulmadığını soruşmalı olacağıq.
Java EE
Sözdə JavaSE (Java Standard Edition) var. Bu konsepsiya bütün sinifləri əhatə edir java, onlardan istifadə etmək üçün onları idxal etmək lazımdır (məsələn, java.util.Date) və ya hətta bunu etmək lazım deyil (məsələn, Stringpaketdə yerləşdiyi üçün java.lang). Və Java EE (Java Enterprise Edition) var. Bu siniflər də Sun/Oracle-a aiddir, lakin yeganə fərq ondan ibarətdir ki, layihədə istifadə etməyə başlamaq daha çətindir. Sadə bir xətt import…kifayət etməyəcək, çünki... layihə tərtib edilməyəcək. Vəziyyəti düzəltmək üçün javaee.jar kitabxana faylını tapmalı və onu layihəyə daxil etməlisiniz . Bu, inkişaf mühitindəki layihə xüsusiyyətləri vasitəsilə edilə bilər. Tez-tez deyilir ki, bu əlaqə prosesi belə adlanır: layihənin qurma yolunda və ya sinif yolunda jar ləqəbini qeyd edin.
Proqramlar serveri
İndi təsəvvür edin ki, biz Java EE-dən istifadə edən servlet layihəmizi tərtib etmişik. Hər şey əladır, amma indi tərtib edilmiş siniflərimizi servlet konteynerinə yerləşdirməliyik. Tutaq ki, bunu etdilər. Tətbiqimiz işləyəcəkmi? Cavab yox. Servletə daxil olduqda, bəzi siniflərin tapılmadığını göstərən istisnalar atılacaq. Niyə? Çünki biz kompilyatoru sürüşərək “aldatmışıq” javaee.jar в classpath, yəni. kompilyator Java EE-dən olan siniflərin yerində olduğunu və sakitləşdiyini gördü, lakin servlet konteyneri bu sinifləri görmür, lakin servletimizdən onlara keçidləri görür. Bu vəziyyət servlet konteynerində həll edilə bilərmi? Əlbəttə bəli, sadəcə olaraq javaee.jar kitabxana faylını servlet konteynerindəki servletimiz olan qovluğa əlavə etməlisiniz . İndi təsəvvür edin ki, belə layihələr çox olacaq və onların hamısı bir Tomcat servlet konteynerində işləyir. Bu o deməkdir ki, bu jar faylını hər bir servletin qovluğuna köçürməli olacaqsınız. Bu, əlverişsiz və yanlışdır. Vəziyyət, bu faylın çoxdan bir nüsxədə olduğu və bütün servletlərin ona daxil ola biləcəyi və öz nüsxəsinə malik olmadığı proqram serveri konsepsiyasını təqdim etməklə həll edildi. Məncə, çox rahat və məntiqlidir. Təbii ki, bütün təlaş bir jar faylı ilə bağlı deyil (mən onu misal kimi verdim) - belə fayllar çoxdur. Ancaq tətbiq serverlərinin bizə verdiyi bütün bunlar deyil. Tətbiq serverləri özləri bir çox resursla, məsələn, verilənlər bazası ilə əlaqə saxlaya bilər. Bu halda, servletimiz belə bir əlaqəni özü aça bilməz, sadəcə onu proqram serverindən götürə bilər. Servlet konteynerində bu mümkün deyil, çünki... konteyner müəyyən dərəcədə ləğv edilmiş proqram serveridir. Konteynerdə servlet həmişə verilənlər bazası ilə əlaqə yaratmalıdır. Belə bir şey... müharibə arxivi Müharibə arxivi nədir? WAR veb-arxivdir. Əslində, bu, hər hansı bir banka kimi, sadəcə bir zip faylıdır. Əsasən, bu, bir çox veb səhifələrdən, jsp səhifələrindən və servlet siniflərindən ibarət veb saytımızı bir zip faylına sığışdırmağın sadəcə bir yoludur. web.xml web.xml yerləşdirmə deskriptoru adlanır. Bu, servlet konteynerinin çaşqınlığa düşməməsi üçün hansı veb-brauzer xətti sorğusunun emal üçün hansı servlet sinfinə göndərilməsini axmaqcasına təsvir edən bir fayldır, hansı servlet nəyə cavabdehdir. Ümumiyyətlə, Java-da hər cür xml fayllarında parametrləri təsvir etmək çox dəbdədir, lakin son vaxtlar bu ənənədən uzaqlaşma tendensiyası müşahidə olunur. Necə, soruşursan? Və annotasiyalar vasitəsilə. Annotasiya siniflərinin özləri heç nə etmir, onlar sadəcə olaraq hər cür parametrləri (meta-məlumatlar) ayrıca xml faylında deyil, birbaşa kodda təsvir etmək üçün yaradılmışdır. Çox rahat. Ancaq indi müəyyən bir aralıq mərhələ var, bəzi parametrlər annotasiyalarla, bəziləri isə xml ilə müəyyən edilir və bu, çaşqınlıq yarada bilər, çünki Siz xml-ə baxırsınız və bir parametr görürsünüz, lakin annotasiyalara görə başqa bir parametr var. Hansı ən yüksək prioritetdir? Kim bilir…
Nəticə
Bunu yazdıqdan sonra düşündüm ki, belə tez bir baxış heç kimə kömək etməyəcək, çünki... heç bir konkretlik və misal yoxdur, amma digər tərəfdən yazılanları silməyin, belə olsun.
GO TO FULL VERSION