Di sinilah bagian "Perusahaan" dari Java EE bertemu dengan dunia nyata.
Premis penggunaan sistem "Perusahaan" sebagian besar berpusat pada manajemen. Secara khusus menyerahkan keputusan dan konfigurasi ke container daripada mengandalkan aplikasi itu sendiri untuk mengelola sumber daya ini. Dengan memisahkan pembuatan dan pengelolaan sumber daya dari kode aplikasi dan mengandalkan wadah, administrator sistem kemudian memiliki visibilitas dan akses ke sumber daya tersebut dan dengan demikian memiliki potensi untuk menyesuaikan dan memantau aplikasi pada tingkat yang lebih tinggi, dan dengan cara yang umum. , daripada menggunakan mekanisme khusus aplikasi untuk ini.
Jadi, itulah lingkungan tempat kita berada dan itulah bagian yang mendorong "aturan" spesifikasi Java EE tentang apa yang bisa dan tidak bisa (tidak boleh) Anda lakukan.
Sekarang, spesifikasi kontainer servlet, lebih liar di barat. Ia tidak memiliki semua fitur manajemen "Perusahaan" ini (ingat, banyak kontainer yang mengeksposnya, tetapi spesifikasi tidak menyebutkannya). Misalnya, menyajikan file statis adalah kemampuan utama dari wadah web, jadi tidak masuk akal untuk membatasi akses ke file tersebut oleh pengembang. Ditambah lagi, spesifikasi servlet hadir sebelum spesifikasi EJB dan dimasukkan ke dalam lingkungan tersebut, bukan dibuat ulang berdasarkan lingkungan tersebut.
Itu memberi Anda dua spesifikasi "kontradiksi" dalam hal hal-hal spesifik (seperti utas).
Jadi, ya, spesifikasi Servlet "memungkinkan Anda" mengelola kumpulan thread Anda sendiri, bahkan dalam aplikasi Java EE, meskipun kumpulan thread tersebut kemungkinan besar berada di JVM yang sama persis (dan dengan demikian "mengkonsumsi sumber daya Java EE secara tidak terkendali") sebagai Wadah Java EE.
Artinya di dunia nyata adalah, ya, jika Anda mau, Anda bisa mengumpulkan thread dan semacamnya di dalam container Java EE, atau di dalam container servlet. Tidak ada wadah populer yang melarang Anda melakukan ini (WebSphere mungkin, saya tidak menggunakannya).
Tapi, sebaiknya jangan. Java EE (terutama Java EE 6) memiliki mekanisme dan rintangan yang dapat Anda lewati untuk melakukan sesuatu daripada menggunakan kumpulan thread. Hal-hal seperti WorkManagers, antrian JMS, kacang Sesi Asinkron, pekerjaan Timer.
Dalam aplikasi servlet, sebagian besar mekanisme ini tidak ada, sehingga Anda tidak dapat memanfaatkannya, dan karenanya Anda menggunakan "hanya Java".
Konsekuensi penggunaan "Just Java" di aplikasi web yang diterapkan dengan aplikasi Java EE adalah visibilitas di dalam container. Misalnya, aplikasi web Anda memerlukan variabel konfigurasinya sendiri untuk menyiapkan ukuran kumpulan threadnya, dan tidak dapat mengandalkan container untuk mengelolanya.
Pada akhirnya, ini biasanya Bukan Masalah Besar. Sebagian besar kompleksitas Java EE berpusat pada kemampuan manajemen yang tidak digunakan banyak orang. Bagi saya sendiri, saya menggunakan Java EE dan jarang menggunakan WAR biasa, saya suka memasukkan sebanyak mungkin ke dalam container -- biarkan ia melakukan tugasnya. Meskipun demikian, saya memiliki server soket khusus yang berjalan di WAR dalam wadah Java EE, melanggar setiap aturan yang dapat dibayangkan, hanya karena hal itu jauh lebih mudah dilakukan. "Java EE Way" tidak cukup fleksibel untuk apa yang ingin kami lakukan, jadi kami menggunakan "Just Java" dan menuangkan kode ke dalam WAR sehingga kami bisa bermain di Wild Wild West, di mana Men are Men dan mengelola thread mereka sendiri.
person
Will Hartung
schedule
31.10.2012
