J2EE 1.4 memudahkan pengembangan layanan Web

Pada akhir presentasi layanan Web J2EE (Java 2 Platform, Enterprise Edition) pada JavaOne tahun lalu, arsitek IBM Jim Knutson mengatakan bahwa "setiap layanan Web membutuhkan tempat untuk menjadi layanan." Dia kemudian menyarankan bahwa tempat paling ideal untuk menjadi layanan Web adalah di dalam infrastruktur J2EE. Sedikit lebih dari setahun kemudian, rilis final J2EE 1.4 sudah dekat, dan janji paling signifikannya adalah untuk mewujudkan visi layanan Web J2EE.

Fitur layanan Web dalam J2EE 1.4 menangani kedua sisi server dan klien layanan Web. Fitur-fitur tersebut memperluas J2EE untuk memungkinkan komponen Java perusahaan sisi server yang ada menjadi layanan Web dan menentukan bagaimana wadah klien J2EE dapat menjalankan layanan Web. Teknologi untuk kedua tujuan tersebut telah ada untuk sementara waktu, dan spesifikasi J2EE yang baru bergantung pada API yang ada untuk dukungan layanan Web. Spesifikasi baru menambah teknologi yang ada satu set persyaratan interoperabilitas, dan model pemrograman dan penyebaran untuk integrasi layanan Web.

Ada dua spesifikasi yang secara eksplisit menguraikan fitur-fitur tambahan tersebut: Java Specification Request 151, payung JSR untuk J2EE 1.4, dan JSR 109, Layanan Web untuk J2EE. Pada saat tulisan ini dibuat, JSR 109 telah mencapai tahap akhir dalam JCP (Java Community Process), sedangkan JSR 151 dalam tahap pemungutan suara terakhir. Selain itu, JCP mengubah rilis final JSR 101, Java API untuk Panggilan Prosedur Jarak Jauh berbasis XML (JAX-RPC), untuk mendukung persyaratan interoperasi J2EE 1.4.

Server aplikasi level 1.3 J2EE juga dapat menerapkan banyak fitur yang ditentukan oleh JSR ini. Memang, banyak vendor server aplikasi telah mendukung berbagai fitur pengembangan dan penerapan layanan Web dalam produk mereka yang sudah ada selama beberapa waktu sekarang. JSR 109 dan 151 mengkodifikasi beberapa praktik yang ada dan menjelaskan mekanisme baru dengan harapan menciptakan model integrasi layanan J2EE-Web universal. Server aplikasi generasi mendatang kemungkinan besar akan mengikuti model terstandarisasi dan terpadu itu.

Setelah survei singkat fitur J2EE terkait layanan Web baru, artikel ini mengulas model pemrograman klien dan server baru, termasuk penyebaran J2EE baru dan peran manajemen layanan yang terkait dengan dukungan layanan Web.

Ekstensi J2EE terkait layanan web

Mungkin yang paling signifikan, dan paling penting, tambahan untuk J2EE adalah persyaratan interoperasi baru. Persyaratan menentukan dukungan untuk SOAP (Simple Object Access Protocol) 1.1 di lapisan presentasi J2EE untuk memfasilitasi pertukaran pesan XML. Kontainer yang sesuai dengan J2EE 1.4 juga harus mendukung Profil Dasar WS-I (Konsorsium Interoperabilitas Layanan Web). Karena pertukaran pesan XML di J2EE bergantung pada JAX-RPC, spesifikasi JAX-RPC sekarang mewajibkan dukungan Profil Dasar WS-I juga.

Hasilnya adalah aplikasi berbasis J2EE 1.4 dapat dipanggil sebagai layanan Web, bahkan dari aplikasi yang tidak ditulis dalam bahasa pemrograman Java. Meskipun itu adalah langkah evolusioner untuk J2EE, karena platform ini telah lama menggunakan sistem berbasis non-Java, ini mungkin cara paling langsung untuk memfasilitasi interaksi dengan teknologi berbasis Windows yang mengandalkan .Net.

Klien layanan berbasis J2EE tidak harus mengetahui bagaimana layanan diimplementasikan. Sebaliknya, klien tersebut dapat menggunakan layanan dengan mengandalkan sepenuhnya pada definisi WSDL (Bahasa Deskripsi Layanan Web) layanan. ( Kolom Layanan Web JavaWorld sebelumnya menjelaskan cara menemukan layanan berdasarkan definisi WSDL mereka, dan cara membuat serta menggunakan definisi WSDL. Lihat Sumber untuk tautan.) Sementara spesifikasi J2EE tidak menjelaskan mekanisme yang tepat dari interaksi tersebut, J2EE 1.4 ' Pelukan WS-I Basic Profile, yang juga diklaim oleh Microsoft, kemungkinan besar akan membuat interaksi J2EE-.Net menjadi umum.

Untuk memfasilitasi akses ke definisi WSDL, J2EE 1.4 menambahkan dukungan untuk standar JAXR (Java API for XML Registries). Library JAXR sekarang menjadi bagian yang diperlukan dari klien aplikasi J2EE, EJB (Enterprise JavaBeans), dan container Web (bukan container applet). Karena Profil Dasar WS-I mengamanatkan dukungan untuk UDDI (Deskripsi Universal, Penemuan, dan Integrasi) 2.0, klien J2EE, serta komponen dan servlet EJB, dapat berinteraksi dengan pendaftar layanan Web publik. ("Layanan Web Terapung dengan JAXR" ( JavaWorld, Mei 2002) menawarkan tutorial tentang JAXR.) Gambar 1 mengilustrasikan pustaka terkait layanan Web tambahan yang didukung oleh J2EE 1.4.

Memang, J2EE mengambil pandangan bahwa layanan Web adalah implementasi dari satu atau lebih antarmuka yang ditentukan oleh dokumen WSDL. Operasi yang dijelaskan dalam WSDL pertama kali dipetakan ke metode Java mengikuti aturan pemetaan WSDL ke Java dari spesifikasi JAX-RPC. Setelah antarmuka Java yang sesuai dengan file WSDL ditentukan, Anda dapat mengimplementasikan metode antarmuka itu dengan salah satu dari dua cara: sebagai kacang sesi stateless yang berjalan di wadah EJB atau sebagai kelas Java yang berjalan di wadah servlet J2EE. Terakhir, Anda mengatur wadah masing-masing untuk mendengarkan permintaan SOAP yang masuk dan memetakan permintaan tersebut ke implementasi masing-masing (EJB atau servlet). Untuk memproses pemanggilan SOAP yang masuk, J2EE 1.4 mengamanatkan runtime JAX-RPC sebagai layanan kontainer J2EE tambahan.

Sesuai dengan arsitektur J2EE, wadah implementasi layanan memediasi akses ke layanan Web: jika Anda mengekspos komponen EJB atau servlet sebagai layanan Web J2EE, klien layanan Anda dapat memanggil layanan itu hanya secara tidak langsung, melalui wadah. Itu memungkinkan implementasi layanan untuk mendapatkan keuntungan dari keamanan wadah, manajemen utas, dan bahkan jaminan kualitas layanan. Selain itu, kontainer memungkinkan Anda membuat keputusan penting layanan Web, seperti batasan keamanan, pada waktu penerapan. Akhirnya, model berbasis kontainer J2EE membuat penyebaran layanan Web portabel: Anda dapat mengembangkan layanan Web berbasis Java menggunakan alat J2EE apa pun dan mengharapkan layanan itu berjalan dalam implementasi kontainer lain yang sesuai.

Klien layanan Web, di sisi lain, tetap tidak menyadari keberadaan wadah layanan Web. Sebaliknya, klien melihat port yang mewakili contoh titik akhir jaringan dari layanan Web. Titik akhir tersebut mengikuti model antarmuka titik akhir layanan (SEI) JAX-RPC dan menyediakan implementasi antarmuka layanan. Seorang klien melihat setiap layanan Web J2EE sebagai SEI dan kombinasi port. Satu kontainer J2EE dapat menampung banyak kombinasi seperti itu, seperti yang diilustrasikan pada Gambar 2. Setiap kombinasi SEI / port adalah turunan dari layanan Web.

Perhatikan bahwa klien dalam arsitektur ini dapat berupa klien J2EE, berjalan di dalam wadah klien J2EE, atau klien non-J2EE. Semua klien yang memenuhi Profil Dasar WS-I dapat menggunakan layanan Web J2EE, tetapi setiap klien dapat mengikuti model pemrograman yang berbeda. Spesifikasi layanan Web J2EE menguraikan model pemrograman untuk klien yang berjalan di dalam wadah klien aplikasi J2EE dan model lain — model pemrograman server — untuk implementasi layanan Web yang dijalankan di wadah EJB atau servlet.

Model pemrograman klien layanan Web J2EE

Inti dari model pemrograman klien layanan Web adalah untuk menyederhanakan penggunaan API yang didefinisikan dalam JSRs 67 (Java APIs for XML Messaging, JAXM), 93 (JAXR), and 101 (JAX-RPC), dan untuk menyediakan kerangka kerja yang komprehensif untuk menggunakan API tersebut bersama-sama dalam wadah klien J2EE.

Sesuai dengan model pemrograman klien J2EE, klien layanan Web dapat dipindahkan dan memberikan transparansi lokal / jarak jauh. Penyedia port layanan Web dan wadah yang menjalankan port menentukan bagaimana klien melihat layanan Web. Klien selalu mengakses port dan tidak pernah memberikan referensi langsung ke implementasi layanan Web. Klien layanan Web J2EE tetap tidak menyadari bagaimana port beroperasi dan harus memperhatikan dirinya sendiri hanya dengan metode yang didefinisikan oleh port. Metode tersebut merupakan antarmuka publik layanan Web. Selain itu, klien harus mempertimbangkan akses ke port layanan Web sebagai stateless di seluruh pemanggilan layanan. Sejauh menyangkut klien, port tidak memiliki identitas unik — klien tidak memiliki cara untuk menentukan apakah port tersebut berkomunikasi dengan port identik di seluruh pemanggilan layanan.

Klien mendapatkan akses ke port berdasarkan antarmuka layanan port. Layanan Web J2EE bergantung pada JAX-RPC untuk menentukan hubungan antara port dan antarmuka layanannya. JAX-RPC membuat hubungan tersebut berdasarkan aturan pemrosesan WSDL. Jadi, definisi WSDL layanan Web pada akhirnya mengatur perilaku port. Berdasarkan definisi JAX-RPC, antarmuka layanan dapat berupa antarmuka umum yang langsung mengimplementasikan javax.xml.rpc.Serviceantarmuka, atau "layanan yang dihasilkan", yang merupakan subtipe dari antarmuka tersebut. Jenis antarmuka yang terakhir khusus untuk jenis layanan Web.

Dalam model pemrograman J2EE, klien mendapatkan referensi ke objek layanan Web Servicemelalui operasi pencarian JNDI (Java Naming and Directory Interface). Pencarian JNDI terjadi dengan nama logis, atau referensi layanan, untuk layanan Web. Seperti dengan semua sumber daya berbasis direktori, klien harus mendeklarasikan sumber daya apa yang dibutuhkannya dalam deskriptor penerapannya (lebih lanjut tentang itu nanti).

Spesifikasi layanan Web Java (JSR 109) merekomendasikan bahwa semua layanan Web dimasukkan di bawah servicesubkonteks JNDI . Kontainer klien mengikat antarmuka layanan yang dijelaskan oleh referensi tersebut di bawah java:comp/envkonteks penamaan lingkungan klien. Dengan mendeklarasikan referensi layanan dalam deskriptor penerapan klien, penampung klien memastikan bahwa layanan yang direferensikan tersedia dalam sumber daya yang sadar JNDI. Potongan kode berikut menunjukkan cara mendapatkan referensi ke layanan Web berbasis J2EE melalui pencarian JNDI:

InitialContext ctx = new InitialContext (); Layanan myService = (Layanan) ctx.lookup ("java: comp / env / services / MyWebService");

Kode di atas memperoleh objek layanan generik: objek tanpa tipe tertentu. Layanan yang dihasilkan JAX-RPC diakses dengan cara yang sama, kali ini mentransmisikan layanan ke jenis antarmuka layanan Web tertentu:

InitialContext ctx = new InitialContext (); MyWebService myService = (MyWebService) ctx.lookup ("java: / comp / env / services / MyWebService");

Perhatikan bahwa kode ini mengasumsikan bahwa MyWebServicereferensi mengikat ke objek yang mengimplementasikan MyWebServiceantarmuka. Karena pengikatan layanan difasilitasi pada waktu penyebaran layanan Web, alat J2EE diharapkan untuk memastikan konsistensi itu. Semua server aplikasi yang sesuai dengan J2EE 1.4 harus mendukung pencarian layanan berbasis JNDI.

Setelah klien mendapatkan objek layanan Web, klien Servicedapat menggunakan objek tersebut untuk mengambil javax.xml.rpc.Callinstance yang menjalankan pemanggilan layanan yang sebenarnya. Klien memiliki tiga opsi untuk mendapatkan Call: melalui stub, proxy layanan dinamis, atau DII (Dynamic Invocation Interface). Saya tidak akan membahas dalam artikel ini perbedaan antara metode tersebut karena, terlepas dari bagaimana a Calldibuat, yang Callmerujuk langsung kembali ke port layanan — satu-satunya objek yang harus diketahui klien saat menjalankan layanan Web. Semua kontainer yang memenuhi J2EE 1.4 harus mendukung Servicemetode antarmuka, dan dengan demikian memungkinkan klien untuk mendapatkan referensi ke Callobjek untuk layanan Web, dan ke port layanan itu, melalui Call.

Perhatikan bahwa berbeda dengan menggunakan JAX-RPC di luar J2EE, klien tidak boleh menggunakan kelas JAX-RPC ServiceFactoryuntuk mendapatkan layanan baru. Sebaliknya, klien harus mendapatkan akses ke Servicedari sumber berbasis JNDI, karena referensi ke layanan yang diambil dari JNDI akan memiliki semua pengaturan dan konfigurasi yang diperlukan untuk menjalankan instance layanan tertentu. Dari sudut pandang klien, perbedaan itu agak mirip dengan bagaimana klien J2EE mengambil JDBC DataSourcemelalui antarmuka JNDI untuk mengakses database, alih-alih mengonfigurasi Connectioninstance JDBC secara manual .

Dengan Callobjek tersebut di tempat, klien mengikuti semantik JAX-RPC panggilan prosedur jarak jauh. Misalnya, klien mungkin menggunakan invoke()metode itu Calluntuk berinteraksi dengan layanan Web. (Untuk contoh permintaan layanan gaya JAX-RPC, lihat "Saya Suka Jenis Anda: Menjelaskan dan Memanggil Layanan Web Berdasarkan Jenis Layanan" ( JavaWorld, September 2002).)

Model pemrograman server layanan Web

Layanan Web berbasis J2EE dapat mengikuti salah satu dari dua kemungkinan implementasi: Jika layanan diimplementasikan sebagai kelas Java reguler, itu harus sesuai dengan persyaratan penampung servlet JAX-RPC. Atau, jika layanan didefinisikan untuk dieksekusi dalam kontainer EJB, maka layanan harus mengikuti model pemrograman yang disyaratkan dari kacang sesi EJB stateless. Terlepas dari metode implementasi, setiap wadah menyediakan implementasi layanan Web dengan dukungan siklus hidup, manajemen konkurensi, dan infrastruktur keamanan.

Tanggung jawab utama penampung server J2EE adalah untuk memetakan dan mengirimkan permintaan SOAP, dalam kasus EJB, ke kacang sesi stateless, dan, dalam kasus kontainer servlet, ke metode di kelas titik akhir layanan JAX-RPC. Sementara spesifikasi JAX-RPC mendefinisikan model pemrograman untuk opsi terakhir, layanan Web J2EE JSR (JSR 109) menguraikan model analog untuk kacang sesi EJB stateless.