Laksanakan ESB yang disesuaikan dengan Java

Pertimbangkan syarikat di mana anda mempunyai aplikasi heterogen, mungkin dihantar oleh pasukan yang berbeza, yang perlu berinteraksi antara satu sama lain tetapi mempunyai kekangan berikut:

  • Setiap aplikasi tidak semestinya dibuat menggunakan teknologi yang sama dan mungkin tidak berbicara dengan yang lain menggunakan mekanisme pemanggilan asalnya, misalnya, aplikasi J2EE dan aplikasi .Net.
  • Sebaiknya, setiap aplikasi tidak boleh mengubah permintaannya menjadi format yang difahami oleh aplikasi sasaran. Tambahan, perusahaan memiliki banyak aplikasi yang menggunakan aplikasi target.
  • Komponen perkhidmatan harus menggunakan mekanisme permintaan atau permintaan yang wajar bagi mereka. Sebagai contoh, aplikasi J2EE yang ada dapat menerima permintaan hanya melalui Java Message Service (JMS).
  • Perusahaan bergerak ke arah seni bina di mana aplikasi hanya mementingkan dirinya sendiri dengan, satu, apa yang diketahui dan, dua, apa yang harus dilalui sebagai parameter ketika ingin mendapatkan perkhidmatan aplikasi lain dalam perusahaan.

Kekangan lain mungkin memerlukan anda mempunyai infrastruktur yang membolehkan aplikasi yang beragam dapat disatukan dengan lancar tanpa mengubah reka bentuknya. Bas perkhidmatan perusahaan (ESB) adalah salah satu cara untuk mewujudkan seni bina integrasi perusahaan.

Walaupun setiap syarikat kemungkinan akan membuat ESB dengan cara yang tersendiri, penting untuk diingat ketika mempertimbangkan definisi ESB. Tidak ada pendekatan tetap untuk membangunnya. Ideanya adalah untuk mempunyai lapisan penyambungan yang mengoptimumkan interaksi antara pengguna perkhidmatan dan penyedia perkhidmatan, yang dapat merespon konteks berorientasikan peristiwa, mesej, atau perkhidmatan.

Artikel ini membincangkan pendekatan untuk membangun ESB berbasis Java yang dapat diperluas yang menyokong keperluan fungsi ESB yang paling umum.

Keperluan ESB biasa

Keperluan umum ESB juga merupakan ciri yang paling biasa digunakan:

  1. Laluan: ESB harus menyediakan mekanisme penghalaan yang cekap dan fleksibel.
  2. Transformasi: Komponen perkhidmatan tidak perlu mengetahui format permintaan perkhidmatan sasaran yang mungkin diminta. Berdasarkan pemohon dan sasaran, ESB harus dapat menerapkan transformasi yang sesuai untuk permintaan sehingga sasaran dapat memahaminya.
  3. Pengangkutan multiprotocol: Pelaksanaan ESB yang hanya membincangkan JMS atau hanya perkhidmatan Web tidak begitu bernilai. Ini harus cukup luas untuk menyokong pelbagai protokol mesej bergantung pada keperluan perusahaan.
  4. Keselamatan: Sekiranya diperlukan, ESB harus menegakkan pengesahan dan kebenaran untuk mengakses komponen perkhidmatan yang berbeza.

Rajah 1 menunjukkan komponen seni bina utama ESB. Ia mempunyai tiga petak luas:

  1. Penerima: ESB memperlihatkan antara muka yang berbeza untuk membolehkan aplikasi pelanggan menghantar mesej ke ESB. Sebagai contoh, servlet dapat menerima permintaan HTTP untuk ESB. Pada masa yang sama, anda mungkin akan mendengar MDB (kacang yang didorong oleh pesan) di destinasi JMS di mana aplikasi pelanggan dapat menghantar mesej.
  2. Teras: Ini adalah bahagian utama pelaksanaan ESB. Ia menangani peralihan dan transformasi, dan menerapkan keselamatan. Biasanya, ia terdiri dari MDB yang menerima permintaan masuk dan kemudian, berdasarkan konteks pesan, menerapkan transformasi, perutean, dan keamanan yang sesuai. Perincian mengenai perutean, pengangkutan, transformasi, dan maklumat keselamatan dapat ditentukan dalam dokumen XML (dibahas tidak lama lagi).
  3. Penghantar: Semua pengendali pengangkutan keluar masuk di bawah bahagian ESB ini. Anda boleh memasukkan mana-mana pengendali pengangkutan sewenang-wenangnya (e-mel, faks, FTP, dll.) Ke ESB.

Semua bahagian ESB ini dilekatkan bersama oleh dokumen XML yang menyenaraikan semua laluan di mana ESB beroperasi. Pengendali pengangkutan yang berbeza, transformer, dan dasar percubaan semula dan sambungannya ke laluan yang berbeza semuanya disambungkan melalui dokumen XML ini.

ESBConfiguration.xml

Penyenaraian XML - ESBConfiguration.xml, yang muncul di bawah - memberi kami beberapa idea mengenai cara kerja ESB. Elemen utama yang menarik ESBConfiguration.xmladalah seperti berikut:

  1. Beans: Elemen ini mengandungi unsur sifar atau lebih Bean.
  2. Bean: Elemen ini pada asasnya menentukan cara kita membuat dan mengkonfigurasi Beankelas. Ia mempunyai sifat berikut:
    • name: Nama unik yang boleh digunakan untuk merujuk kacang ini.
    • className: Nama kelas kacang yang layak sepenuhnya.
    Setiap kacang boleh mempunyai Propertyunsur sifar atau lebih seperti kanak-kanak. Setiap Propertyelemen mempunyai atribut nameyang mengenalinya dan elemen jenis anak Valueyang menyimpan nilai harta tanah. Sifat-sifat ini sebenarnya adalah ahli gaya JavaBeans kelas yang dapat mengkonfigurasi kelas kacang.
  3. RetryPolicies: Elemen ini mengandungi RetryPolicykanak - kanak sifar atau lebih .
  4. RetryPolicy: Elemen ini menentukan dasar percubaan untuk laluan tertentu. Ia mempunyai atribut nameyang dapat digunakan untuk merujuknya. Ia mempunyai dua unsur anak bernama MaxRetriesdan RetryInterval.
  5. Route: EsbConfigurationElemen akar boleh mengandungi unsur anak sifar atau lebih dari jenis ini. Ini pada dasarnya mewakili laluan untuk ESB. Ia mempunyai sifat berikut:
    • name: Nama unik yang boleh digunakan untuk merujuk kepada laluan ini.
    • retryPolicyRef: Rujukan kepada dasar percubaan semula. Ia harus sesuai dengan atribut RetryPolicyelemen name.
    • transformerRef: Rujukan pada kacang yang mewakili pengubah. Ia harus sesuai dengan atribut Beanelemen name.
    The Routeunsur boleh mempunyai satu atau lebih elemen anak jenis TransportHandlerRef. Anak ini pada dasarnya menunjukkan kacang yang mewakili pengendali pengangkutan yang sesuai yang harus digunakan untuk laluan ini, dan nama kaedah umum kacang itu yang harus dipanggil untuk menghantar mesej. Secara pilihan, Routeelemen tersebut dapat memiliki satu DeadLetterDestinationanak yang menunjuk ke jalan lain yang mewakili destinasi mati.

Contoh dokumen XML EsbConfiguration.xml, muncul di bawah:

                              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    

Kelakuan ESB

The ESBConfiguration.xmldokumen menentukan tingkah laku ESB kita. The EsbRouterbeban MDB XML ini dari lokasi yang dinyatakan dalam huraian penempatan itu. Maklumat yang dikandungnya kemudian disusun ke dalam infrastruktur data yang digambarkan dalam Rajah 2 di bawah.

Penggunaan EsbRoutermaklumat ini (melalui EsbConfigManager) untuk menguraikan laluan yang sesuai, transformasi, jika ada, untuk diterapkan, pemeriksaan kebenaran keselamatan, dll. Perkara penting yang perlu diperhatikan adalah cara teknik Dependency Injection, bersama dengan warisan, telah digunakan untuk mencabut pelbagai fungsi (seperti penghantaran mesej multiprotocol dan transformasi mesej) ESB, sehingga memungkinkannya untuk diperluas dan disesuaikan.

Seperti yang ditunjukkan oleh rajah kelas, dua antara muka penting terdapat dalam reka bentuk ESB: TransformHandlerdan TransportHandler. Mereka membolehkan anda menulis transformasi dan pelaksanaan pengangkutan tertentu untuk mesej yang diarahkan. Kelas pelaksanaan ini kemudian dapat disambungkan dengan laluan melalui Beanelemen di EsbConfiguration. Sebagai contoh, dalam contoh EsbConfiguration.xmldokumen, definisi kacang berikut menentukan pengendali pengangkutan:

   myQCF   myCreditQueue   

Pengendali pengangkutan ini kemudian dapat disebut dalam Routesimpul dengan memasukkan TransportHandleranak kepadanya seperti ini:

Catatan
Pendekatan yang dijelaskan dalam artikel ini menggunakan antaramuka Java untuk menentukan pengendali pengangkutan dan transformasi. Oleh itu, mana-mana pengendali baru harus melaksanakan antara muka yang diperlukan, yang mungkin kelihatan mengganggu. Anda dapat dengan mudah mengubah EsbConfigManagerpenggunaan Dependency Injection untuk memanggil kaedah sewenang-wenangnya dari kelas pelaksanaan, sehingga menghilangkan kebutuhan untuk melaksanakan antarmuka. Tetapi kerana contoh EsbRouterselalu berlaku javax.jms.Message, kelas pelaksanaan pengendali anda mesti menggunakan jenisnya javax.jms.Messagepula.