Бул темада мен сервлеттер жөнүндө түшүнүгүм жөнүндө, сервлет контейнерлери деген эмне, веб-фронттук фреймворктердин көбү, эгер баары болбосо да, эмне экендиги жөнүндө ачык айткым келет, ошондой эле сервлет контейнерлери жана тиркеме serverлери менен кандай байланышы бар деген темага токтолгум келет. бири-бирине жана сервлет жана веб-server контейнерлери. Сүйлөшүүнү баштоонун алдында, мен чындап эле талкуу болорун күткөнүмдү белгилегим келет, анткени... Бул жерде мен бир даана code бергим келбейт, бирок жөн гана сөз менен айтууга боло турган маңызына токтолгум келет. Мен биринчи баштаганда мага түшүнүксүз болгон бардык пункттарды кыскача айтып берүүгө аракет кылам. Мен ар кандай форумдарда Tomcat сервлет контейнери ар кандай тиркеме serverинен эмнеси менен айырмаланат деген темада суроолорду бергенимде, айталы, WebSphere же Геронимо, жооп берүүгө батынган адамдар гана "Википедияны карагыла" же " дегенден башка эч нерсе айта алышпайт. деп айтуу кыйын, serverдик тиркемелер - бул корпоративдик тиркемелер үчүн татаал инфраструктура, ал..." бла бла бла. Мен андай адамдарга чыдай албайм жана көпчүлүгүңүздөр да чыдаbyte деп ойлойм. Тарыхый адилетсиздикти оңдойбуз. Барыңыз…
Сервлеттер
Ким эмне десе да, сервлет бул Java тorнде жазылган веб-баракча. Кээ бирөөлөр мен жаңылып жатам жана сервлет бул веб-тиркеме жана бул түшүнүктөрдүн айырмасы бар деп айтышат, бирок андай эмес. Эми эч кандай айырма жок жана PHPде жазылган сайттарды да коопсуз веб-тиркемелер деп атоого болот. Эми бул толугу менен табигый нерсе, анткени... php толугу менен OOP колдойт жана Joomla сыяктуу CMSлер муну жигердүү колдонушат. Код деңгээлиндеги сервлет деген эмне? Бул GET же POST HTTP сурамдары аркылуу кимдир-бирөө аларга кирээрин же жокпу, уктаган бир нече методдор бар класс. Ошол. Биз браузерде кандайдыр бир GET суроо-талабын тердик, сервлет классынын тиешелүү ыкмасы аны кабыл алып, андан кийин ага HTML баракчасы түрүндө жоопту жаратат. Сервлеттин классикалык маанисинде, аны Sun ойлоп тапкандай, бул барак кардарга <!DOCTYPE htm>> сабынан башталып, </html> сабына чейин сап боюнча жөнөтүлгөн. Ошентип, Javaда негизги сервлет классы бар Servlet. Кошумчалай кетсек, бул базалык класстан мураска алынган жана ошону менен анын функционалдуулугун кеңейтүүчү башка класстардын бир тобу бар. Сервлет деген ушул - башка эч нерсе эмес. Бул жөн гана PHP codeунун Java аналогу, ал serverде да аткарылат жана кардарга веб-баракча түрүндө веб-браузердин суроо-талабына жооп гана жөнөтүлөт. Баары.
Веб алдыңкы алHowтары
Субтитр татаал жана адатта алар жөн гана фронталдык фреймворк же алтургай веб мурду жазышат , бирок мен бул жерде фронттук алHowтар жөнүндө сөз кылганда, веб-браузер аркылуу Java менен иштөө үчүн GUI жөнүндө сөз болуп жатканын баса белгилеп кетүүнү чечтим. Ошол. бул жерде дагы бир жолу Java тorндеги веб-сайттар жөнүндө сөз болуп жатат, б.а. сервлеттер жөнүндө. Дээрлик бардык фронталдык алHow деген эмне, мисалы, Apache Struts. Бул жөн гана базалык классты кеңейтүүчү класстардын жыйындысы Servlet. Башка эч нерсе. Ошол. бул бир эле кадимки сервлетти түзүүнүн башка жолу. Бул негизди иштеп чыгуучулар (же башкача айтканда, бул технологияны иштеп чыгуучулар) Servletкээ бир методдор менен базалык классты кошуу программист үчүн Sun/Oracle классикалык сервлетинин азыраак функционалдуулугуна караганда ыңгайлуураак деп эсептешкен. бар.
JSP баракчалары
Дээрлик дароо эле Java сервлет концепциясын иштеп чыгуучулардын оюна дагы бир идея келди. Биз сервлет жазып жаткандыктан, анын милдети кардарга html баракчасын жөнөтүү, анда бул html баракты дароо жазуу туурараак болушу мүмкүн, эгер сизге Java-да кандайдыр бир логика керек болсо, анда аны түз эле киргизиңиз. htmlге. Эгерде ал түшүнүксүз болуп калса, анда сөз айкашы жардам бериши мүмкүн: jsp баракчасы PHP баракчасынын аналогу. Кыйынбы? Анда мен дагы түшүндүрөм. PHPде барак жазганда эмне кылабыз? Бизде статикалык HTML бар жана PHPге циклдер жана шарттар сыяктуу каалаган логиканы киргизүү керек болгондо, биз аны тегтин негизги бөлүгүнө киргизебиз <?php … ?>. jsp менен баары бирдей, логика гана таза Java тorнде жазылган, анын codeу тегтин корпусуна киргизилген <% … %>. Дагы бир жолу сервлет түшүнүгүнө кайрылып көрөлү. Негизи, JSP баракчасы сервлет, бирок бир аз башкача жазылган. Кадимки сервлетте биз кандайдыр бир логиканы аткарган методду жазабыз жана анын жыйынтыгы боюнча кардар үчүн HTML барагын түзөбүз. Болгону, бир нече убакыт өткөндөн кийин, сервлетти иштеп чыгуучулар ойлоно башташты: эгер методдо логика дээрлик жок болсо жана html барагынын түзүлүшү гана пайда болсо, анда дароо html баракчасын жазуу оңой болбойт беле? минималдуу Java кыстармаларын жасоо үчүн кайсынысы? Jsp баракчалары жөнүндө акыркы нерсе. Мындай бетке биринчи жолу киргенде, ал сервлетке түзүлөт жана андан кийин аткарылат. Бул jsp баракчасына кийинки суроо-талаптар тезирээк болот, анткени ал мурунтан эле түзүлөт жана аны аткаруу гана керек болот.
Сервлет контейнери
Ошентип, биз сервлет классын же JSP барагын жаздык. Кийинкиси эмне? Аларды колдонуучунун веб-браузерине жөнөтүү үчүн, аларды веб-serverге кантип түртүүгө болот, айталы, apache? Веб server html гана жөнөтө алат, эгер биздин баракчада айталы, php codeу болсо, анда веб-server алгач баракты phpти htmlге которгон котормочу аркылуу өткөрүп берет, андан кийин гана натыйжа кардарга жөнөтүлөт. Ошол эле нерсе сервлеттерде болот - жөнөтүүдөн мурун, алар HTML барагын түзүү үчүн аткарылышы керек, ал эми сервлет контейнери дал ушул сервлеттерди жана jsp бет codeун аткарууга жооптуу нерсе. Ошол. Java үчүн сервлет контейнери веб-serverдеги PHP котормочу модулунун аналогу болуп саналат. Ошентип, колдонуучу веб-браузерге даректи киргизгенде, суроо-талап веб-serverге жөнөтүлөт, веб-server сервлет суралып жатканын түшүнөт жана суроо-талапты сервлет контейнерине өткөрүп берет. Андан кийин, сервлет контейнери сервлетті аткарат, натыйжада HTML баракты веб-serverге жөнөтөт, ал өз кезегинде аны кардарга кайтарат. Сервлет контейнери өз алдынча иштей алабы, б.а. веб-serverсизби? Tomcat сыяктуу бир нерсе сөзсүз болот. Жана эгер биз сервлеттерге негизделгенден башка HTML баракчалары жок сайт түзгүбүз келсе, анда биз үчүн сервлет контейнери жетиштүү. Бирок, эгерде биз сайтты сервлеттерден жана айталы, PHP барактарынан бириктиргибиз келсе, анда веб-serverди орнотууга туура келет. Мындан тышкары, бардык веб-serverлерде демейки боюнча камтылган сервлет контейнери жок, бирок дээрлик бардыгы аны плагин катары орнотууга мүмкүндүк берет. Ошондуктан, эгер биз веб-сайтыбызды Apache иштеген Интернеттеги кандайдыр бир хостингде ишке киргизгибиз келсе, анда провайдерден сервлет контейнери туташкан-тушпаганын сурашыбыз керек болот.
Java EE
JavaSE (Java Standard Edition) деп аталган бар. Бул түшүнүк бардык класстарды камтыйт java, аларды колдонуу үчүн биз аларды импорттообуз керек (мисалы, java.util.Date) же муну жасоонун кереги жок (мисалы, Stringал пакетте жайгашкандыктан java.lang). Жана Java EE (Java Enterprise Edition) бар. Бул класстар да Sun/Oracleга таандык, бирок бир гана айырмасы, аларды долбоордо колдонууну баштоо кыйыныраак. Жөнөкөй сызык import…жетишсиз болот, анткени... долбоор түзүлбөйт. Кырдаалды оңдоо үчүн javaee.jar китепкана файлын таап , аны долбоорго кошушуңуз керек . Бул өнүгүү чөйрөсүндөгү долбоордун касиеттери аркылуу жасалышы мүмкүн. Бул туташуу процесси деп көп айтылат: долбоордун куруу жолунда же класс жолунда jar лакап атын каттаңыз.
Тиркемелер serverи
Эми биз Java EEди колдонгон сервлет долбоорубузду түздүк деп элестетиңиз. Баары сонун, бирок биз эми компиляцияланган класстарыбызды сервлет контейнерине жайгаштырышыбыз керек. Муну алар жасады дейли. Биздин колдонмо иштейби? Жооп жок. Сервлетке киргенде, кээ бир класстар табылбаганын көрсөтүүчү өзгөчөлүктөр ыргытылат. Неге? Анткени биз компиляторду тайгаланып "алдап" койгонбуз javaee.jar в classpath, б.а. компилятор Java EE класстарынын ордунда экенин жана тынчып калганын көрдү, бирок сервлет контейнери бул класстарды көрбөйт, бирок биздин сервлеттен аларга шилтемелерди көрөт. Бул жагдай сервлет контейнеринде чечилеби? Албетте, ооба, сиз жөн гана javaee.jar китепкана файлын сервлет контейнериндеги биздин сервлет менен папкага кошушуңуз керек . Эми мындай долбоорлор көп болорун элестетиңиз жана алардын баары бир Tomcat сервлет контейнеринде иштеп жатат. Бул сиз бул jar файлын ар бир сервлеттин папкасына көчүрүп алышыңыз керек дегенди билдирет. Бул ыңгайсыз жана туура эмес. Кырдаал тиркеме serverинин концепциясын киргизүү жолу менен чечилди, анда бул файл көптөн бери бир нускада болгон жана бардык сервлеттер ага кире алат жана өзүнүн көчүрмөсү жок. Менимче, бул абдан ыңгайлуу жана логикалуу. Албетте, бардык ызы-чуу бир jar файлына байланыштуу эмес (мен аны мисал катары келтирдим) - мындай файлдар көп. Бирок бул колдонмо serverлери бизге берген бардык нерсе эмес. Колдонмо serverлери өзүлөрү көптөгөн ресурстар менен, мисалы, маалымат базасы менен байланышты камсыздай алат. Бул учурда, биздин сервлет мындай байланышты өзү ачпашы мүмкүн, бирок аны жөн гана колдонмо serverинен алат. Сервлет контейнеринде бул мүмкүн эмес, анткени... контейнер белгилүү бир деңгээлде ажыратылган колдонмо serverи болуп саналат. Контейнерде сервлет ар дайым маалымат базасына байланыш түзүшү керек. Ушундай бир нерсе... согуш-архив Согуш архиви деген эмне? WAR бул веб-архив. Чынында, бул ар кандай банка сыяктуу эле zip файлы. Негизинен, бул көптөгөн веб-баракчалардан, jsp баракчаларынан жана сервлет класстарынан турган биздин веб-сайтты бир zip файлына жыйноо ыкмасы. web.xml web.xml жайгаштыруу дескриптору деп аталган. Бул сервлет контейнери баш аламан болбошу үчүн кайсы веб-браузердин линиясын иштетүү үчүн кайсы сервлет классына жөнөтүү өтүнүчүн келесоо сүрөттөгөн файл. Жалпысынан, Java-да ар кандай xml файлдарында орнотууларды сүрөттөө абдан модалуу, бирок жакында бул салттан алыстап кетүү тенденциясы байкалды. Кантип, сен сурайсыңбы? Жана annotationлар аркылуу. Аннотация класстары өздөрү эч нерсе кылbyte, алар жөн гана ар кандай орнотууларды (мета-маалыматтар) өзүнчө xml файлында эмес, түздөн-түз codeдо сүрөттөө үчүн түзүлгөн. Абдан ыңгайлуу. Бирок, азыр кээ бир орнотуулар annotationлар менен, ал эми кээ бирлери xml менен көрсөтүлгөн белгилүү бир ортоңку этап бар жана бул чаташтырышы мүмкүн, анткени Сиз xmlди карап, бир жөндөөнү көрөсүз, бирок annotationларга ылайык башкасы бар. Кайсынысы эң артыкчылыктуу? Ким билет…
Корутунду
Муну жазгандан кийин мындай тез карап чыгуу эч кимге жардам бербейт деп ойлогом, анткени... эч кандай конкреттүүлөрдү жана эч кандай мисалдарды камтыbyte, бирок экинчи жагынан, жазылганды өчүрбөңүз, ошондой болсун.
GO TO FULL VERSION