Panduan pemula untuk Enterprise JavaBeans

Enterprise JavaBeans (EJB) telah menghasilkan banyak kegembiraan sejak pengumuman Maret 1998 tentang Enterprise JavaBeans Spesifikasi Versi 1.0. Perusahaan seperti Oracle, Borland, Tandem, Symantec, Sybase, dan Visigenic, di antara banyak lainnya, telah mengumumkan dan / atau mengirimkan produk yang sesuai dengan spesifikasi EJB. Bulan ini, kita akan melihat tingkat tinggi apa sebenarnya Enterprise JavaBeans itu. Kami akan membahas bagaimana EJB berbeda dari model komponen JavaBeans asli, dan membahas mengapa EJB menarik minat yang begitu besar.

Tapi pertama-tama, sebuah nasihat: kami tidak akan melihat pada kode sumber atau topik petunjuk bulan ini. Artikel ini bukan tutorial; melainkan gambaran arsitektur. EJB mencakup banyak wilayah, dan tanpa terlebih dahulu memahami konsep dasar yang terlibat, potongan kode dan trik pemrograman tidak ada artinya. Jika ada minat dari pembaca JavaWorld , artikel mendatang mungkin membahas secara spesifik penggunaan Enterprise JavaBeans API untuk membuat Enterprise JavaBeans Anda sendiri.

Untuk memahami mengapa EJB sangat menarik bagi pengembang, kami membutuhkan latar belakang sejarah. Pertama, kita akan melihat sejarah sistem klien / server, dan keadaan saat ini. Kemudian, kita akan membahas berbagai bagian dari sistem EJB: komponen EJB - yang hidup di kontainer EJB yang berjalan di dalam server EJB - dan objek EJB, yang digunakan klien sebagai semacam "kendali jarak jauh" komponen EJB . Kita akan membahas dua jenis EJB: objek sesi dan entitas . Anda juga akan membaca tentang rumah dan remoteantarmuka, yang membuat instans EJB dan menyediakan akses ke metode bisnis EJB. Di akhir artikel, Anda akan memiliki gambaran tentang bagaimana server yang dapat diperluas dapat dibangun menggunakan Enterprise JavaBeans. Tapi pertama-tama, lihat kembali ke masa lalu.

Riwayat klien / server

Sejarah kuno

Awalnya, ada komputer mainframe. Dan itu bagus. (Atau sebagus yang didapat). Keadaan seni dalam pemrosesan informasi selama tahun 1960-an terutama terdiri dari mesin besar dan mahal yang digunakan oleh organisasi besar untuk mendukung operasi bisnis harian mereka. Komputer mini dan berbagi waktu pada tahun 1970-an meningkatkan aksesibilitas daya komputasi, tetapi informasi dan pemrosesan masih terpusat pada masing-masing mesin. Komputer pribadi pertama di tahun 1980-an dengan cepat mengacaukan lanskap perusahaan dengan ribuan pulau kecil informasi, semua tanpa lelah mengeluarkan laporan dengan kualitas variabel, kehilangan data penting saat rusak, dan dengan cepat menjadi tidak konsisten satu sama lain.

Klien / server untuk menyelamatkan

Arsitektur klien / server adalah salah satu solusi paling umum untuk teka-teki tentang bagaimana menangani kebutuhan untuk kontrol data terpusat dan aksesibilitas data yang luas. Dalam sistem klien / server, informasi disimpan secara relatif terpusat (atau dipartisi dan / atau direplikasi di antara server terdistribusi), yang memfasilitasi kontrol dan konsistensi data, sambil tetap menyediakan akses ke data yang dibutuhkan pengguna.

Sistem klien-server sekarang umumnya terdiri dari berbagai tingkatan. Sistem mainframe atau timesharing standar yang lama, di mana antarmuka pengguna berjalan pada komputer yang sama dengan database dan aplikasi bisnis, yang dikenal sebagai single tier. Sistem seperti ini relatif mudah dikelola, dan konsistensi datanya sederhana karena data disimpan hanya di satu tempat. Sayangnya, sistem satu tingkat memiliki skalabilitas terbatas dan rentan terhadap bahaya ketersediaan (jika satu komputer mati, seluruh bisnis Anda turun), terutama jika komunikasi terlibat.

Sistem klien / server pertama adalah sistem dua tingkat, di mana antarmuka pengguna dijalankan pada klien, dan database berada di server. Sistem seperti itu masih umum. Satu jenis server dua tingkat varietas taman melakukan sebagian besar logika bisnis pada klien, memperbarui data bersama dengan mengirimkan aliran SQL ke server. Ini adalah solusi yang fleksibel, karena percakapan klien / server terjadi pada tingkat bahasa database server. Dalam sistem seperti itu, klien yang dirancang dengan baik dapat dimodifikasi untuk mencerminkan aturan dan ketentuan bisnis baru tanpa memodifikasi server, selama server memiliki akses ke skema database (tabel, tampilan, dan sebagainya) yang diperlukan untuk melakukan transaksi. Server dalam sistem dua tingkat seperti itu disebut server database, seperti yang ditunjukkan di bawah ini.

Server database memiliki beberapa kewajiban. Seringkali SQL untuk fungsi bisnis tertentu (misalnya, menambahkan item ke pesanan) identik, dengan pengecualian data yang diperbarui atau disisipkan, dari panggilan ke panggilan. Server database akhirnya melakukan parsing dan reparsing SQL yang hampir identik untuk setiap fungsi bisnis. Misalnya, semua pernyataan SQL untuk menambahkan item ke pesanan kemungkinan besar sangat mirip, seperti pernyataan SQL untuk menemukan pelanggan di database. Waktu yang dibutuhkan untuk penguraian ini akan lebih baik jika digunakan untuk memproses data. (Ada solusi untuk masalah ini, termasuk cache parse SQL dan prosedur tersimpan.) Masalah lain yang muncul adalah membuat versi klien dan database pada saat yang sama: semua mesin harus dimatikan untuk peningkatan,dan klien atau server yang tertinggal dalam versi perangkat lunak mereka biasanya tidak dapat digunakan sampai mereka ditingkatkan.

Server aplikasi

Sebuah aplikasi server arsitektur (lihat gambar berikutnya) adalah alternatif yang populer untuk arsitektur database server karena memecahkan beberapa masalah database server memiliki.

Lingkungan server database biasanya menjalankan metode bisnis pada klien, dan menggunakan server sebagian besar untuk ketekunan dan penegakan integritas data. Di server aplikasi, metode bisnis dijalankan di server, dan klien meminta agar server menjalankan metode ini. Dalam skenario ini, klien dan server biasanya akan menggunakan protokol yang mewakili percakapan di tingkat transaksi bisnis, bukan di tingkat tabel dan baris. Server aplikasi seperti itu sering kali berkinerja lebih baik daripada rekan database mereka, tetapi mereka masih mengalami masalah versi.

Baik sistem database dan aplikasi dapat ditingkatkan dengan menambahkan tingkatan tambahan ke arsitektur. Yang disebut sistem tiga tingkat menempatkan komponen perantara antara klien dan server. Seluruh industri - middleware - telah dipotong untuk mengatasi kewajiban sistem dua tingkat. Sebuah Monitor transaksi-pengolahan,satu jenis middleware, menerima aliran permintaan dari banyak klien, dan dapat menyeimbangkan beban antara beberapa server, menyediakan failover ketika server gagal, dan mengelola transaksi atas nama klien. Jenis middleware lainnya menyediakan terjemahan protokol komunikasi, mengkonsolidasikan permintaan dan tanggapan antara klien dan beberapa server heterogen (ini sangat populer dalam menangani sistem warisan dalam rekayasa ulang proses bisnis), dan / atau menyediakan pengukuran layanan dan informasi lalu lintas jaringan.

Berbagai tingkatan memberikan fleksibilitas dan interoperabilitas yang menghasilkan sistem dengan lebih dari tiga lapisan layanan ini. Misalnya, sistem n-tier adalah generalisasi dari sistem tiga tingkat, setiap lapisan perangkat lunak menyediakan tingkat layanan yang berbeda untuk lapisan di atas dan di bawahnya. Perspektif n-tier menganggap jaringan sebagai kumpulan layanan terdistribusi, bukan sekadar sarana bagi klien untuk mengakses satu server.

Karena bahasa dan teknik berorientasi objek mulai populer, begitu pula sistem klien / server semakin bergerak ke arah orientasi objek. CORBA (Common Object Request Broker Architecture) adalah arsitektur yang memungkinkan objek dalam aplikasi - bahkan objek yang ditulis dalam bahasa berbeda - untuk berjalan di mesin terpisah, bergantung pada kebutuhan aplikasi tertentu. Aplikasi yang ditulis bertahun-tahun yang lalu dapat dikemas sebagai layanan CORBA dan dapat dioperasikan dengan sistem baru. Enterprise JavaBeans, yang dirancang agar kompatibel dengan CORBA, adalah entri lain ke dalam ring server aplikasi berorientasi objek.

Tujuan artikel ini bukan untuk memberikan tutorial tentang sistem klien / server, tetapi perlu untuk memberikan beberapa latar belakang untuk menentukan konteks. Sekarang mari kita lihat apa yang ditawarkan EJB.

Enterprise JavaBeans dan server aplikasi yang dapat diperluas

Sekarang kita telah melihat sedikit sejarah dan memiliki pemahaman tentang apa itu server aplikasi, mari kita lihat Enterprise JavaBeans dan lihat apa yang ditawarkannya dalam konteks itu.

Ide dasar di balik Enterprise JavaBeans adalah menyediakan kerangka kerja untuk komponen yang dapat "dicolokkan" ke server, sehingga memperluas fungsionalitas server tersebut. Enterprise JavaBeans mirip dengan JavaBeans asli hanya karena ia menggunakan beberapa konsep serupa. Teknologi EJB diatur bukan oleh Spesifikasi Komponen JavaBeans, tetapi oleh Spesifikasi JavaBeans Enterprise yang sama sekali berbeda (dan masif) . (Lihat Sumber untuk rincian tentang spesifikasi ini.) Spesifikasi EJB memanggil berbagai pemain dalam sistem klien / server EJB, menjelaskan bagaimana EJB beroperasi dengan klien dan dengan sistem yang ada, menjelaskan kompatibilitas EJB dengan CORBA, dan menentukan tanggung jawab untuk berbagai komponen dalam sistem.

Sasaran Enterprise JavaBeans

The EJB Spec mencoba untuk memenuhi beberapa tujuan sekaligus:

  • EJB dirancang untuk memudahkan pengembang membuat aplikasi, membebaskannya dari detail sistem tingkat rendah untuk mengelola transaksi, utas, penyeimbangan beban, dan sebagainya. Pengembang aplikasi dapat berkonsentrasi pada logika bisnis dan menyerahkan detail pengelolaan pemrosesan data ke kerangka kerja. Namun, untuk aplikasi khusus, selalu mungkin untuk "tersembunyi" dan menyesuaikan layanan tingkat yang lebih rendah ini.

  • The EJB Spec mendefinisikan struktur utama dari kerangka EJB, dan kemudian secara khusus mendefinisikan kontrak antara mereka. Tanggung jawab klien, server, dan komponen individu semuanya dijabarkan dengan jelas. (Kita akan membahas apa struktur ini sebentar lagi.) Seorang pengembang yang membuat komponen Enterprise JavaBean memiliki peran yang sangat berbeda dari seseorang yang membuat server yang sesuai dengan EJB, dan spesifikasinya menjelaskan tanggung jawab masing-masing.

  • EJB bertujuan untuk menjadi cara standar untuk aplikasi klien / server yang akan dibangun dalam bahasa Java. Sama seperti JavaBeans asli (atau komponen Delphi, atau apa pun) dari vendor yang berbeda dapat digabungkan untuk menghasilkan klien khusus, komponen server EJB dari vendor berbeda dapat digabungkan untuk menghasilkan server khusus. Komponen EJB, sebagai kelas Java, tentu saja akan berjalan di server yang mendukung EJB tanpa kompilasi ulang. Ini adalah manfaat yang tidak dapat ditawarkan oleh solusi khusus platform.

  • Terakhir, EJB kompatibel dengan dan menggunakan API Java lainnya, dapat beroperasi dengan aplikasi non-Java, dan kompatibel dengan CORBA.

Bagaimana sistem klien / server EJB bekerja

Untuk memahami bagaimana sistem klien / server EJB beroperasi, kita perlu memahami bagian dasar dari sistem EJB: komponen EJB, wadah EJB, dan objek EJB.

Komponen Enterprise JavaBeans

Enterprise JavaBean adalah sebuah komponen, seperti JavaBean tradisional. Enterprise JavaBeans mengeksekusi dalam wadah EJB, yang pada gilirannya dieksekusi dalam server EJB. Server apa pun yang dapat menghosting container EJB dan menyediakan layanan yang diperlukan dapat menjadi server EJB. (Ini berarti bahwa banyak server yang ada dapat diperluas menjadi server EJB, dan pada kenyataannya banyak vendor telah mencapai ini, atau telah mengumumkan niat untuk melakukannya.)

Komponen EJB adalah jenis kelas EJB yang paling mungkin dianggap sebagai "Enterprise JavaBean". Ini adalah kelas Java, yang ditulis oleh pengembang EJB, yang mengimplementasikan logika bisnis. Semua kelas lain dalam sistem EJB mendukung akses klien ke atau menyediakan layanan (seperti ketekunan, dan seterusnya) ke kelas komponen EJB.

Kontainer Enterprise JavaBeans

Wadah EJB adalah tempat komponen EJB "hidup". Kontainer EJB menyediakan layanan seperti manajemen transaksi dan sumber daya, pembuatan versi, skalabilitas, mobilitas, persistensi, dan keamanan ke komponen EJB yang dikandungnya. Karena wadah EJB menangani semua fungsi ini, pengembang komponen EJB dapat berkonsentrasi pada aturan bisnis, dan meninggalkan manipulasi basis data dan detail halus lainnya ke wadah. Misalnya, jika satu komponen EJB memutuskan bahwa transaksi saat ini harus dibatalkan, itu hanya memberi tahu penampungnya (dengan cara yang ditentukan oleh Spesifikasi EJB, dan penampung bertanggung jawab untuk melakukan semua rollback, atau melakukan apa pun yang diperlukan untuk membatalkan transaksi sedang berlangsung. Beberapa contoh komponen EJB biasanya ada di dalam satu wadah EJB.

Objek EJB dan antarmuka jarak jauh

Program klien mengeksekusi metode pada EJB jarak jauh melalui objek EJB. Objek EJB mengimplementasikan "antarmuka jarak jauh" dari komponen EJB di server. Antarmuka jarak jauh mewakili metode "bisnis" dari komponen EJB. Antarmuka jarak jauh melakukan pekerjaan objek EJB yang sebenarnya dan berguna, seperti membuat formulir pemesanan atau menyerahkan pasien ke spesialis. Kami akan membahas antarmuka jarak jauh lebih detail di bawah ini.