JavaRush /Blog Java /Random-MS /Tanpa kesedihan. Mari kita bercakap tentang Java EE, serv...
eGarmin
Tahap

Tanpa kesedihan. Mari kita bercakap tentang Java EE, servlet dan bekasnya

Diterbitkan dalam kumpulan
Dalam topik ini, saya ingin terus terang bercakap tentang pemahaman saya tentang servlet, apakah bekas servlet, apakah kebanyakan, jika tidak semua, rangka kerja hadapan web, dan juga menyentuh topik tentang bagaimana bekas servlet dan pelayan aplikasi berkaitan dengan satu sama lain, dan servlet dan bekas pelayan web. Tanpa kesedihan.  Mari kita bercakap tentang Java EE, servlet dan bekasnya - 1Sebelum memulakan perbualan, saya ingin ambil perhatian bahawa saya sangat mengharapkan bahawa akan ada perbincangan, kerana... Di sini saya tidak mahu memberikan sekeping kod, tetapi hanya ingin menyentuh intipati, yang sentiasa boleh dinyatakan dalam perkataan. Saya akan cuba menggariskan semua perkara yang tidak jelas kepada saya semasa saya mula-mula. Apabila saya bertanya soalan di pelbagai forum mengenai topik bagaimana bekas servlet Tomcat berbeza daripada mana-mana pelayan aplikasi, katakan WebSphere atau Geronimo, satu-satunya orang yang berani menjawab adalah orang bodoh yang tidak dapat berkata apa-apa selain "lihat Wikipedia" atau " sukar untuk mengatakan, aplikasi pelayan - ini adalah infrastruktur yang kompleks untuk aplikasi korporat, yang..." bla bla bla. Saya tidak tahan dengan orang seperti itu dan saya rasa kebanyakan anda juga tidak. Kami akan membetulkan ketidakadilan sejarah. Pergi…

Servlets

Tidak kira apa yang orang katakan, servlet ialah halaman web yang ditulis dalam Java. Sesetengah akan mengatakan bahawa saya salah dan bahawa servlet ialah aplikasi web dan terdapat perbezaan dalam konsep ini, tetapi ini tidak begitu. Kini tiada perbezaan, dan tapak yang ditulis dalam PHP juga boleh dipanggil aplikasi web dengan selamat. Sekarang ini benar-benar semula jadi, kerana... php menyokong sepenuhnya OOP, dan CMS seperti Joomla secara aktif menggunakan ini. Apakah servlet pada tahap kod? Ini ialah kelas yang mempunyai beberapa kaedah yang tidur dan melihat jika seseorang mengaksesnya melalui permintaan HTTP GET atau POST. Itu. Kami menaip beberapa permintaan GET dalam penyemak imbas, kaedah kelas servlet yang sepadan menerimanya dan kemudian menjana respons kepadanya dalam bentuk halaman HTML. Dalam erti kata klasik servlet, seperti yang dibayangkan oleh Sun, halaman ini dihantar kepada klien baris demi baris, bermula dengan baris <!DOCTYPE htm>> dan berakhir dengan baris </html>. Jadi di Jawa terdapat kelas servlet asas yang dipanggil Servlet. Di samping itu, terdapat sekumpulan kelas lain yang mewarisi daripada kelas asas ini dan dengan itu memanjangkan fungsinya. Itulah servlet - tidak lebih. Ia hanya analog Java kod PHP, yang juga dilaksanakan pada pelayan, dan hanya respons kepada permintaan pelayar web dalam bentuk halaman web dihantar kepada klien. Semua.

Rangka kerja bahagian hadapan web

Sari kata adalah rumit dan biasanya mereka hanya menulis rangka kerja bahagian hadapan atau pun muncung web , tetapi saya memutuskan untuk menekankan di sini bahawa apabila kita bercakap tentang rangka kerja bahagian hadapan, kita bercakap tentang GUI untuk bekerja dengan Java melalui pelayar web. Itu. di sini sekali lagi kita bercakap tentang laman web di Jawa, i.e. mengenai servlet. Apakah hampir semua rangka kerja bahagian hadapan, contohnya, Apache Struts. Ia hanyalah satu set kelas yang memanjangkan kelas asas Servlet. Tidak lebih. Itu. ia hanyalah cara yang berbeza untuk mencipta servlet biasa yang sama. Cuma pembangun rangka kerja ini (atau dengan kata lain, pembangun teknologi ini) menganggap bahawa penambahan kelas asas mereka Servletdengan beberapa kaedah akan lebih mudah untuk pengaturcara daripada fungsi yang tidak seberapa yang servlet klasik dari Sun/Oracle mempunyai.

halaman JSP

Hampir serta-merta, idea lain muncul di fikiran pembangun konsep servlet Java. Oleh kerana kami sedang menulis servlet, tugasnya adalah untuk menghantar halaman html kepada klien, maka mungkin lebih tepat untuk segera menulis halaman html ini, dan jika anda memerlukan beberapa jenis logik dalam Java, maka masukkannya secara langsung ke dalam html. Jika ia tidak menjadi lebih jelas, maka frasa itu boleh membantu: halaman jsp ialah analog halaman php. Sukar? Kemudian saya akan menerangkan lagi. Apa yang kita lakukan semasa menulis halaman dalam PHP? Kami mempunyai html statik, dan apabila kami perlu memasukkan sebarang logik dalam PHP seperti gelung dan syarat, kami memasukkannya ke dalam badan teg <?php … ?>. Dengan jsp semuanya adalah sama, hanya logiknya ditulis dalam Java tulen, kod yang dimasukkan ke dalam badan tag <% … %>. Mari kembali kepada konsep servlet sekali lagi. Pada dasarnya, halaman JSP ialah servlet, tetapi ditulis sedikit berbeza. Dalam servlet biasa, kami menulis kaedah yang melaksanakan beberapa logik dan, berdasarkan keputusannya, menjana halaman HTML untuk klien. Hanya selepas beberapa lama, pembangun servlet mula berfikir: bagaimana jika tiada logik dalam kaedah itu, dan hampir hanya pembentukan halaman html berlaku, maka bukankah lebih mudah untuk segera menulis halaman html ke dalam yang mana untuk membuat kod sisipan Java? Nah, satu perkara terakhir tentang halaman jsp. Kali pertama halaman sedemikian diakses, ia disusun ke dalam servlet dan kemudian dilaksanakan. Permintaan seterusnya ke halaman jsp ini akan menjadi lebih pantas kerana ia sudah pun disusun dan hanya perlu dilaksanakan.

Bekas Servlet

Jadi kami menulis kelas servlet atau halaman JSP. Apa yang akan datang? Bagaimana untuk menolaknya ke dalam pelayan web, katakan apache, supaya ia boleh menghantarnya ke pelayar web pengguna? Pelayan web hanya boleh menghantar html, dan jika halaman kami mempunyai, katakan, kod php, maka pelayan web mula-mula menghantar halaman melalui penterjemah yang menterjemahkan php ke dalam html, dan hanya kemudian hasilnya dihantar kepada pelanggan. Perkara yang sama berlaku dengan servlet - sebelum menghantar, ia perlu dilaksanakan agar halaman HTML dijana, dan bekas servlet adalah perkara yang bertanggungjawab untuk melaksanakan servlet dan kod halaman jsp. Itu. Bekas servlet untuk java ialah analog modul penterjemah php dalam pelayan web. Oleh itu, apabila pengguna memasukkan alamat dalam pelayar web, permintaan dihantar ke pelayan web, pelayan web memahami bahawa servlet sedang diminta dan menghantar permintaan itu kepada bekas servlet. Selepas ini, bekas servlet melaksanakan servlet, menghantar halaman HTML yang terhasil ke pelayan web, yang seterusnya, mengembalikannya kepada klien. Bolehkah bekas servlet berjalan sendiri, i.e. tanpa pelayan web? Sesuatu seperti Tomcat pasti boleh. Dan jika kita ingin mencipta tapak yang tidak akan mempunyai halaman html lain kecuali yang berdasarkan servlet, maka bekas servlet sudah cukup untuk kita. Tetapi jika kita ingin menggabungkan tapak daripada servlet dan, katakan, halaman PHP, maka kita perlu memasang pelayan web. Selain itu, tidak semua pelayan web mempunyai bekas servlet yang disertakan secara lalai, tetapi hampir semuanya membenarkan anda memasangnya sebagai pemalam. Oleh itu, jika kami ingin melancarkan laman web kami pada beberapa pengehosan di Internet, di mana Apache kemungkinan besar dijalankan, maka kami perlu bertanya kepada pembekal sama ada bekas servlet disambungkan.

Java EE

Terdapat apa yang dipanggil JavaSE (Java Standard Edition). Konsep ini merangkumi semua kelas java, untuk kegunaannya kita hanya perlu mengimportnya (contohnya, java.util.Date) atau bahkan tidak perlu melakukan ini (contohnya, Stringkerana ia terletak dalam pakej java.lang). Dan terdapat Java EE (Java Enterprise Edition). Kelas ini juga tergolong dalam Sun/Oracle, tetapi satu-satunya perbezaan ialah kelas ini lebih sukar untuk mula digunakan dalam projek. Baris ringkas import…tidak akan mencukupi, kerana... projek tidak akan disusun. Untuk membetulkan keadaan, anda perlu mencari fail perpustakaan javaee.jar dan memasukkannya ke dalam projek. Ini boleh dilakukan melalui hartanah projek dalam persekitaran pembangunan. Selalunya dikatakan bahawa proses sambungan ini dipanggil: daftar nama samaran balang dalam laluan binaan atau laluan kelas projek.

Pelayan aplikasi

Sekarang bayangkan bahawa kami telah menyusun projek servlet kami yang menggunakan Java EE. Segala-galanya bagus, tetapi kini kami perlu meletakkan kelas terkumpul kami dalam bekas servlet. Katakan mereka melakukannya. Adakah permohonan kami akan berfungsi? Jawapannya adalah tidak. Apabila mengakses servlet, pengecualian akan dilemparkan menunjukkan bahawa beberapa kelas tidak dijumpai. kenapa? Kerana kami "menipu" penyusun dengan tergelincir javaee.jar в classpath, i.e. pengkompil melihat bahawa kelas dari Java EE telah disediakan dan tenang, tetapi bekas servlet tidak melihat kelas ini, tetapi ia melihat pautan kepada mereka dari servlet kami. Adakah keadaan ini boleh diselesaikan dalam bekas servlet? Sudah tentu ya, anda hanya perlu menambah fail perpustakaan javaee.jar pada folder dengan servlet kami dalam bekas servlet . Sekarang bayangkan bahawa akan ada banyak projek sedemikian dan semuanya berjalan dalam satu bekas servlet Tomcat. Ini bermakna anda perlu menyalin fail jar ini ke folder setiap servlet. Ini menyusahkan dan salah. Keadaan ini telah diselesaikan dengan memperkenalkan konsep pelayan aplikasi, di mana fail ini telah lama berada dalam satu salinan, dan semua servlet boleh mengaksesnya, dan tidak mempunyai salinan mereka sendiri. Pada pendapat saya, ia sangat mudah dan logik. Sememangnya, semua kekecohan bukan disebabkan oleh satu fail balang (saya memberikannya sebagai contoh) - terdapat banyak fail sedemikian. Tetapi bukan itu sahaja yang pelayan aplikasi berikan kepada kami. Pelayan aplikasi sendiri boleh mengekalkan sambungan kepada banyak sumber, contohnya, pangkalan data. Pada masa yang sama, servlet kami mungkin tidak membuka sambungan sedemikian sendiri, tetapi hanya mengambilnya dari pelayan aplikasi. Dalam bekas servlet, ini adalah mustahil, kerana... bekas adalah, pada tahap tertentu, pelayan aplikasi yang dilucutkan. Dalam bekas, servlet mesti sentiasa membuat sambungan ke pangkalan data itu sendiri. Sesuatu seperti ini... war-archive Apa itu war-archive? WAR ialah arkib web. Sebenarnya, ia hanyalah fail zip, seperti mana-mana balang. Pada asasnya, ini hanyalah satu cara untuk menjejalkan laman web kami, yang terdiri daripada banyak halaman web, halaman jsp dan kelas servlet, ke dalam satu fail zip. web.xml web.xml ialah apa yang dipanggil deskriptor penempatan. Ini adalah fail yang dengan bodohnya menerangkan permintaan talian pelayar web mana untuk dihantar ke kelas servlet mana untuk diproses, supaya bekas servlet tidak keliru, servlet mana yang bertanggungjawab untuk apa. Secara umum, di Jawa adalah sangat bergaya untuk menerangkan tetapan dalam semua jenis fail xml, tetapi baru-baru ini terdapat kecenderungan untuk beralih daripada tradisi ini. Bagaimana, anda bertanya? Dan melalui anotasi. Kelas anotasi sendiri tidak melakukan apa-apa; mereka dicipta hanya untuk menerangkan semua jenis tetapan (meta-data) bukan dalam fail xml yang berasingan, tetapi secara langsung dalam kod. Sangat selesa. Walau bagaimanapun, kini terdapat peringkat pertengahan tertentu, apabila beberapa tetapan ditentukan oleh anotasi, dan beberapa oleh xml, dan ini boleh mengelirukan, kerana Anda melihat xml dan melihat satu tetapan, tetapi menurut anotasi terdapat satu lagi. Yang manakah mempunyai keutamaan tertinggi? Siapa tahu…

Kesimpulan

Setelah menulis ini, saya fikir semakan pantas itu tidak akan membantu sesiapa pun, kerana... tidak mengandungi apa-apa spesifik dan tiada contoh, tetapi sebaliknya, jangan padamkan apa yang tertulis, jadi biarlah.
Komen
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION