Apa itu ESB dan apa gunanya?

Pada pekerjaan sebelumnya, banyak sekali pembicaraan tentang "Enterprise Service Bus" (ESB). Saya membaca bagian dari buku konseptual tentang hal itu, tetapi tidak pernah benar-benar memahami bagaimana Anda akan menerapkan / mengintegrasikannya dalam istilah konkret. Saya akrab dengan SOA / antrian / layanan direktori / etc. tapi saya tidak mengerti apa sebenarnya ESB itu.

Apakah itu hal yang konkret (layanan / server / broker / dll.) Bahwa Anda hanya menghubungkan semua aplikasi Anda dengan itu dengan cara yang berbeda, atau lebih hanya cara konseptual untuk merancang sistem?

Penjelasan atau tautan apa pun ke contoh yang baik akan sangat dihargai. Terima kasih.

Ini adalah konsep abstraksi tingkat tinggi. Konsep utamanya adalah bahwa ESB menyediakan middleware dan antarmuka yang memungkinkan bisnis menghubungkan aplikasi mereka tanpa menulis kode.

Ini dapat mencakup mediasi untuk merekonsiliasi protokol, data, dan interaksi yang tidak kompatibel.

Gagasan tentang bus pusat tempat segala sesuatu lewat memberi peluang bagi lapisan abstraksi tambahan. Menggunakan standar industri untuk "menyambungkan" aplikasi lain, klien, dan semacamnya ke dalam bus ini, sehingga menghubungkan layanan baru, sumber data, klien dengan kebutuhan yang berbeda relatif mudah.

Implementasi yang sebenarnya

Sejauh implementasi aktual, itulah domain dari bisnis pendukung perusahaan yang sangat besar. Meskipun sangat populer, tujuannya adalah cita-cita yang pada tingkat kecil dapat dipahami melalui perbandingan dengan internet:

Kesamaan dengan Internet

Satu bus komunikasi besar dengan penggunaan dan data yang sangat berbeda, tetapi semuanya menjalankan protokol standar.

Faktanya, seseorang dapat menulis konektor HTTP ke FTP yang memungkinkan browser mengakses situs FTP tanpa meminta klien FTP (biasanya sudah terpasang di browser sekarang).

Mashup

Mashup mendemonstrasikan implementasi yang menarik - ambil beberapa data rute bus dari otoritas San Francisco, peta dari google, dan lokasi bar sushi dari yahoo dengan peringkat dan jalankan kueri sederhana yang memberi Anda bar sushi terdekat, lakukan pembobotan sehingga Anda bisa bersedia melakukan perjalanan sedikit lebih jauh untuk mendapatkan bar yang lebih baik.

Semua layanan yang sama sekali berbeda, tidak kompatibel sendiri-sendiri, tetapi menggunakan konektor standar (pipa yahoo, misalnya) mereka dapat digabungkan menjadi satu kesatuan yang kohesif dan berguna.

-Adam

Penafian: Saya bekerja untuk IBM dan berkonsultasi di WebSphere ESB, produk IBM yang dirancang untuk membuat ESB. Berikut ini adalah pendapat saya dan belum tentu mencerminkan posisi IBM.

ESB adalah hal yang berbeda bagi orang yang berbeda, sayangnya.

Bagi saya, ESB adalah teknologi apa pun yang dapat Anda masukkan ke dalam SOA (Service-Oriented Architecture), memungkinkan Anda untuk menghubungkan sistem yang berbeda bersama-sama. Ini sering melakukan fungsi transformasi protokol, modifikasi pesan, perutean, logging, bertindak sebagai gateway keamanan, dan sebagainya. Misalnya, Anda mungkin menggunakan ESB untuk mengekspos layanan yang sebelumnya hanya tersedia sebagai Layanan Web sebagai layanan berbasis JMS juga.

Dalam hal ini, implementasi ESB (atau lebih tepatnya, perangkat lunak yang dijual untuk membangun ESB dengan - seperti yang saya konsultasikan) sering kali secara teknologi mirip dengan apa yang dulu dikenal sebagai broker perpesanan atau antrian, meskipun tujuannya agak berbeda , karena (seperti yang tersirat dalam akronimnya) ini berorientasi pada layanan daripada memindahkan pesan dari satu tempat ke tempat lain. Seberapa penting perbedaan secara teknologi adalah masalah opini.

Pengalaman saya dengan ESB komersial adalah bahwa ini adalah teknologi yang berlebihan dan mahal yang menciptakan banyak masalah saat dipecahkan. ESB akan menghubungkan sistem dan warisan baru, pesan akan terbang di atas bus dan semuanya akan dapat berbicara dengan yang lainnya dengan mulus. Lemparkan ke dalam beberapa ketahanan, orkestrasi dan Anda memiliki perangkat lunak aplikasi perusahaan yang sangat kuat.

Masalahnya muncul ketika Anda mencoba menggunakannya secara nyata, overhead penulisan untuk bus, membuat struktur pesan, dan sebagainya, dapat melebihi manfaatnya. Sebagai item berbiaya tinggi, ESB dipandang sebagai obat mujarab untuk semua masalah teknologi yang sebenarnya bukan, terlalu banyak waktu yang dihabiskan di bus dan bukan pada aplikasi / data yang sedang dihubungkan. Seringkali terjadi beberapa standar yang bersaing akan memperjuangkan supremasi di organisasi yang sama yang mengarah ke silo yang didominasi teknologi klasik yang seharusnya diperbaiki oleh sistem ini.

IMHO, jauh lebih baik menggunakan membuat sejumlah kecil antarmuka khusus, biasanya menggunakan layanan web hanya antara sistem yang membutuhkannya.

Ini pada dasarnya adalah cara konseptual untuk merancang sistem - perusahaan perangkat lunak mencoba menjual lebih banyak kepada Anda dengan menempelkan stiker 'ESB' di atasnya dan manajer menyukainya karena ESB terlihat bagus dari 'tingkat yang lebih tinggi'.

ESB pada dasarnya adalah MOM (middleware berorientasi pesan) dengan model data tambahan dan manajemen definisi struktur. Anda memiliki definisi data umum untuk semua aplikasi dan adaptor di bus itu (bisa berupa XML dengan XSD bersama). Apa pun yang terhubung HARUS mengirimkan informasi yang sesuai dengan definisi data ini. ESB mendukung pemuatan, pembagian, dan pembuatan versi dari definisi data umum ini. Saat menghubungkan komponen baru ke ESB, Anda dapat mengharapkan lebih banyak 'kompatibilitas' di luar kotak daripada saat menghubungkannya ke MOM. Setiap komponen di bus itu secara konseptual diperlakukan sebagai 'sumber daya' - jadi ada abstraksi tambahan yang diperkenalkan untuk memisahkan pengirim dari penerima.

Contoh: katakanlah Anda ingin menghubungkan aplikasi A dengan aplikasi B dalam middleware berorientasi pesan standar, mari kita gunakan JMS. Anda berbicara dengan kolega Anda yang mengerjakan aplikasi B, menyetujui topik, jenis pesan, dan bidang, lalu mengirimkannya (kode semu): sendJms ("TRADE.MSFT", {MapMessage trader = "pete" price = 101,4 vol = 100})

Jika Anda melakukan hal yang sama dalam arsitektur berorientasi layanan, Anda harus melakukannya

1. instal perangkat lunak tambahan
2. mempelajari banyak konsep baru
3. tentukan komponen Java baru Anda di gui admin ESB
4. menerapkan beberapa antarmuka yang dikontrol oleh ESB
5. sendJms (getDestination (), {MapMessage trader = "pete" price = 101.4 vol = 100}) - perhatikan bahwa tujuan diinjeksi dari ESB

Pertama kali mungkin agak menyakitkan, tapi saya rasa Anda bisa terbiasa, sama seperti Anda bisa terbiasa dengan EJB ;-)

Bisa dibilang sistem MOM adalah 'untyped' (struktur dinamis) sedangkan ESB adalah 'typed' (struktur statis). Pengorbanan dari Pesan mentah vs ESB mirip dengan pilihan lain yang tidak diketik / diketik:

• REST vs. SOAP
• XML vs XML yang tidak divalidasi dengan XSD
• Groovy vs. Java
• bahasa yang ditafsirkan vs. bahasa yang dikompilasi

Untuk proyek yang lebih kecil, lebih baik untuk memilah fungsionalitas dengan cepat (misalnya kode Groovy) tetapi untuk proyek yang lebih besar, ada baiknya memiliki debugger (misalnya Java), untuk diperingatkan terlebih dahulu ketika ada yang rusak dan memiliki standar untuk orang-orang sebelumnya mereka berkomitmen pada proyek.

Jadi, jika proyek Anda menderita karena terlalu banyak orang yang merusak sistem dengan memeriksa perubahan yang tidak divalidasi - beralihlah ke lebih banyak struktur (ESB daripada MOM). Jika proyek Anda menderita karena tidak menyelesaikan cukup banyak hal tepat waktu - pilih solusi yang lebih sederhana dan tidak berjenis. Jika keduanya - dapatkan konsultan (bercanda ;-)

Nah, itu tergantung pada siapa Anda bertanya ... Banyak yang akan mengatakan itu adalah bagian dari "Middleware" yang menghubungkan berbagai bagian "logika bisnis" bersama untuk mengambil kode dari pesan antar modul ini. Saya pikir itu definisi yang cukup umum, tetapi saya yakin Anda sudah mendapatkannya melalui Wikipedia dan yang lainnya.

Mereka yang ingin memiliki ESB hebat untuk menyelamatkan dunia melihatnya seperti yang paling sering disajikan, pusat untuk melakukan segalanya. Sebagian besar upaya implementasi ESB untuk merangkum semua tugas berulang yang kita lihat dalam perangkat lunak bisnis. Itu berarti sebagian besar ESB menangani transfer data, keamanan, logging, terjemahan protokol, sistem kejadian, paparan api melalui layanan web, dll.

Saya pikir itu sejelas mungkin ... Harapan yang membantu.

Lihatlah presentasi saya " Spoiled for Choice - Bagaimana memilih ESB yang tepat ".

Saya menjelaskan kapan harus menggunakan ESB, Integration Suite, atau hanya Kerangka Integrasi (seperti Apache Camel). Saya juga membahas perbedaan antara ESB open source dan proprietary.

Di luar definisi standar yang bisa Anda dapatkan dari Wikipedia . Menurut saya, ini adalah alat yang hebat untuk menghubungkan banyak sistem lama di berbagai platform dan teknologi. Ini juga merupakan alat yang baik untuk membangun alur kerja terdistribusi dan sistem manajemen negara (seperti buku besar).

Namun, ini agak mahal, rumit, dan tidak nyaman untuk dipertahankan dan diperluas yang menjadikannya pilihan teknologi yang buruk sebagai alat tujuan umum untuk menskalakan aplikasi Anda.