Menerapkan ESB yang dapat disesuaikan dengan Java

Pertimbangkan perusahaan di mana Anda memiliki aplikasi heterogen, mungkin dikirimkan oleh tim yang berbeda, yang perlu berinteraksi satu sama lain tetapi memiliki batasan berikut:

  • Setiap aplikasi tidak perlu dibuat menggunakan teknologi yang sama dan tidak dapat berkomunikasi dengan yang lain menggunakan mekanisme pemanggilan aslinya misalnya, aplikasi J2EE dan aplikasi .Net.
  • Lebih disukai, setiap aplikasi tidak boleh mengubah permintaannya ke dalam format yang dipahami oleh aplikasi target. Plus, perusahaan memiliki banyak aplikasi yang menggunakan aplikasi target.
  • Komponen layanan harus menggunakan mekanisme permintaan atau permintaan yang wajar bagi mereka. Misalnya, aplikasi J2EE yang ada hanya dapat menerima permintaan melalui Java Message Service (JMS).
  • Perusahaan sedang bergerak menuju arsitektur di mana aplikasi hanya memperhatikan dirinya sendiri dengan, satu, apa yang diketahuinya dan, dua, apa yang harus diteruskan sebagai parameter ketika ia ingin mendapatkan layanan dari aplikasi lain dalam perusahaan.

Batasan lain mungkin mengharuskan Anda memiliki infrastruktur yang memungkinkan aplikasi heterogen berintegrasi dengan mulus tanpa mengubah desainnya. Bus layanan perusahaan (ESB) adalah salah satu cara untuk mewujudkan arsitektur integrasi perusahaan seperti itu.

Meskipun setiap perusahaan kemungkinan besar akan membuat ESB-nya dengan caranya sendiri yang unik, penting untuk tetap mempertimbangkan fleksibilitas saat mempertimbangkan definisi ESB. Tidak ada pendekatan tetap untuk membangunnya. Idenya adalah untuk memiliki lapisan konektivitas yang mengoptimalkan interaksi antara konsumen layanan dan penyedia layanan, lapisan yang dapat merespons konteks berorientasi acara, pesan, atau layanan.

Artikel ini membahas pendekatan untuk membangun ESB berbasis Java yang dapat diperluas yang mendukung persyaratan fungsional ESB yang paling umum.

Persyaratan ESB umum

Persyaratan umum ESB juga merupakan fitur yang paling umum digunakan:

  1. Perutean: ESB harus menyediakan mekanisme perutean yang efisien dan fleksibel.
  2. Transformasi: Komponen layanan tidak perlu mengetahui format permintaan layanan target yang mungkin dipanggil. Berdasarkan pemohon dan target, ESB harus dapat menerapkan transformasi yang sesuai dengan permintaan sehingga target dapat memahaminya.
  3. Transportasi multiprotokol: Implementasi ESB yang hanya berbicara JMS atau hanya layanan Web tidak banyak nilainya. Ini harus cukup dapat diperluas untuk mendukung beberapa protokol pesan tergantung pada kebutuhan perusahaan.
  4. Keamanan: Jika diperlukan, ESB harus memberlakukan otentikasi dan otorisasi untuk akses ke komponen layanan yang berbeda.

Gambar 1 menunjukkan komponen arsitektur utama ESB. Ini memiliki tiga kompartemen luas:

  1. Penerima: ESB memperlihatkan antarmuka yang berbeda untuk memungkinkan aplikasi klien mengirim pesan ke ESB. Misalnya, servlet dapat menerima permintaan HTTP untuk ESB. Pada saat yang sama, Anda dapat memiliki MDB (kacang berbasis pesan) yang mendengarkan di tujuan JMS di mana aplikasi klien dapat mengirim pesan.
  2. Inti: Ini adalah bagian utama dari implementasi ESB. Ini menangani perutean dan transformasi, dan menerapkan keamanan. Biasanya, ini terdiri dari MDB yang menerima permintaan masuk dan kemudian, berdasarkan konteks pesan, menerapkan transformasi, perutean, dan keamanan yang sesuai. Detail tentang perutean, pengangkutan, transformasi, dan informasi keamanan dapat ditentukan dalam dokumen XML (dibahas sebentar lagi).
  3. Penerima: Semua penangan transportasi keluar berada di bawah bagian ESB ini. Anda dapat menyambungkan pengendali transportasi sembarang (email, faks, FTP, dll.) Ke ESB.

Semua bagian ESB ini direkatkan dengan dokumen XML yang mencantumkan semua rute di mana ESB beroperasi. Penangan transportasi, transformator, dan kebijakan percobaan ulang yang berbeda dan koneksi mereka ke rute yang berbeda semuanya dihubungkan melalui dokumen XML ini.

ESBConfiguration.xml

Daftar XML— ESBConfiguration.xml, yang muncul di bawah — memberi kita gambaran tentang cara kerja ESB. Elemen utama yang menarik ESBConfiguration.xmladalah sebagai berikut:

  1. Beans: Elemen ini berisi nol atau lebih Beanelemen.
  2. Bean: Elemen ini pada dasarnya mendefinisikan cara kita membuat dan mengkonfigurasi Beankelas. Ini memiliki atribut berikut:
    • name: Nama unik yang digunakan untuk menyebut kacang ini.
    • className: Nama kelas kacang yang sepenuhnya memenuhi syarat.
    Setiap kacang dapat memiliki nol atau lebih Propertyelemen sebagai anak. Setiap Propertyelemen memiliki atribut nameyang mengidentifikasinya dan elemen turunan dari tipe Valueyang menyimpan nilai properti. Properti ini sebenarnya adalah anggota kelas bergaya JavaBeans yang dapat mengkonfigurasi kelas kacang.
  3. RetryPolicies: Elemen ini berisi nol atau lebih RetryPolicyturunan.
  4. RetryPolicy: Elemen ini mendefinisikan kebijakan coba lagi untuk rute tertentu. Ini memiliki atribut nameyang dapat digunakan untuk merujuknya. Ini memiliki dua elemen anak bernama MaxRetriesdan RetryInterval.
  5. Route: EsbConfigurationElemen root dapat berisi nol atau lebih elemen turunan dari jenis ini. Ini pada dasarnya mewakili rute untuk ESB. Ini memiliki atribut berikut:
    • name: Nama unik yang dapat digunakan untuk merujuk ke rute ini.
    • retryPolicyRef: Referensi ke kebijakan coba lagi. Itu harus cocok dengan atribut RetryPolicyelemen name.
    • transformerRef: Referensi ke kacang yang mewakili trafo. Itu harus cocok dengan atribut Beanelemen name.
    The Routeelemen dapat memiliki satu atau lebih elemen anak dari jenis TransportHandlerRef. Anak ini pada dasarnya menunjuk ke kacang yang mewakili penangan transportasi yang tepat yang harus digunakan untuk rute ini, dan nama metode publik kacang itu yang harus dipanggil untuk mengirim pesan. Secara opsional, Routeelemen dapat memiliki satu DeadLetterDestinationturunan yang menunjuk ke rute lain yang mewakili tujuan huruf mati.

Contoh dokumen XML EsbConfiguration.xml,, muncul di bawah ini:

                              qcf-1   myCreditQueue     //www.tax.com/calc      file:///C:/temp/esb/transform/xsl/credit.xsl     file:///C:/temp/esb/transform/custom/configManager.properties      qcf-1   Redelivery.Queue     qcf-1   System.DL.Queue     qcf-1   System.Error.Queue     qcf-1   Redelivery.Request.Topic       10 100   10 500    

Perilaku ESB

The ESBConfiguration.xmldokumen mendikte perilaku ESB kita. The EsbRouterbeban MDB XML ini dari lokasi yang ditentukan dalam descriptor deployment nya. Informasi yang dikandungnya kemudian diatur ke dalam struktur data yang digambarkan pada Gambar 2 di bawah ini.

The EsbRoutermenggunakan informasi ini (melalui EsbConfigManager) menguraikan dengan tepat, transformasi, jika ada, yang akan diterapkan, otorisasi keamanan cek, dll Hal yang penting untuk diperhatikan adalah cara teknik Dependency Injection, bersama dengan warisan, telah digunakan untuk memisahkan berbagai fungsi (seperti transportasi pesan multiprotokol dan transformasi pesan) ESB, sehingga memungkinkannya menjadi sangat dapat diperluas dan dapat disesuaikan.

Seperti yang ditunjukkan diagram kelas, dua antarmuka penting ada dalam desain ESB: TransformHandlerdan TransportHandler. Mereka memungkinkan Anda untuk menulis transformasi khusus dan implementasi transport untuk pesan yang dirutekan. Kelas implementasi ini kemudian dapat dihubungkan dengan rute melalui Beanelemen di EsbConfiguration. Misalnya, dalam EsbConfiguration.xmldokumen contoh , definisi kacang berikut menentukan penangan transport:

   myQCF   myCreditQueue   

Penangan transport ini kemudian dapat dirujuk dalam sebuah Routenode dengan memasukkan TransportHandleranak ke dalamnya seperti ini:

Catatan
Pendekatan yang dijelaskan dalam artikel ini menggunakan antarmuka Java untuk menentukan penangan transport dan transform. Dengan demikian, setiap penangan baru harus mengimplementasikan antarmuka yang diperlukan, yang mungkin tampak mengganggu. Anda dapat dengan mudah mengubah EsbConfigManagerpenggunaan Injeksi Dependensi untuk memanggil metode arbitrer apa pun dari kelas implementasi, sehingga menghilangkan kebutuhan untuk mengimplementasikan antarmuka. Tetapi karena instance EsbRouterselalu melewati javax.jms.Message, kelas implementasi penangan Anda harus tetap menggunakan tipe javax.jms.Messagetersebut.