MuleSoft - Proyek Mule
Motivasi di balik proyek Mule adalah -
untuk mempermudah pemrogram,
kebutuhan akan solusi ringan dan modular yang dapat menyesuaikan skala dari kerangka kerja perpesanan tingkat aplikasi ke kerangka kerja yang sangat terdistribusi di seluruh perusahaan.
Mule ESB dirancang sebagai kerangka kerja yang digerakkan oleh peristiwa serta terprogram. Ini digerakkan oleh peristiwa karena dikombinasikan dengan representasi pesan terpadu dan dapat diperluas dengan modul yang dapat dicolokkan. Ini terprogram karena pemrogram dapat dengan mudah menanamkan beberapa perilaku tambahan seperti pemrosesan pesan tertentu atau transformasi data khusus.
Sejarah
Perspektif sejarah proyek Mule adalah sebagai berikut -
Proyek SourceForge
Proyek Mule dimulai sebagai proyek SourceForge pada April 2003, dan setelah 2 tahun versi pertamanya dirilis dan dipindahkan ke CodeHaus. API Objek Pesan Universal (UMO) adalah inti dari arsitekturnya. Ide di balik UMO API adalah untuk menyatukan logika sambil tetap mengisolasi mereka dari transport yang mendasarinya.
Versi 1.0
Ini dirilis pada bulan April 2005 berisi banyak transportasi. Fokus utama dari banyak versi lain yang diikuti olehnya, adalah pada debugging dan penambahan fitur baru.
Versi 2.0 (Adopsi Musim Semi 2)
Spring 2 sebagai kerangka konfigurasi dan kabel diadopsi di Mule 2 tetapi terbukti menjadi over-haul utama karena kurangnya ekspresi konfigurasi XML yang diperlukan. Masalah ini telah diatasi ketika konfigurasi berbasis skema XML telah diperkenalkan di musim semi 2.
Membangun dengan Maven
Peningkatan terbesar yang menyederhanakan penggunaan Mule, baik pada waktu pengembangan maupun penerapan, adalah penggunaan Maven. Dari versi 1.3, itu mulai dibangun dengan Maven.
MuleSource
Pada tahun 2006, MuleSource bergabung "untuk membantu mendukung dan mengaktifkan komunitas yang berkembang pesat menggunakan Mule dalam aplikasi perusahaan yang sangat penting". Itu terbukti menjadi tonggak penting untuk Proyek Mule.
Pesaing Mule ESB
Berikut adalah beberapa pesaing utama Mule ESB -
- WSO2 ESB
- Bus Layanan Oracle
- Broker Pesan WebSphere
- Platform Aurea CX
- Fiorano ESB
- Gateway WebSphere DataPower
- Kerangka Proses Bisnis Hari Kerja
- Bus Layanan Talend Enterprise
- Bus Layanan JBoss Enterprise
- iWay Service Manager
Konsep Inti Mule
Seperti yang telah dibahas, Mule ESB adalah bus layanan perusahaan (ESB) berbasis Java yang ringan dan sangat skalabel serta platform integrasi. Terlepas dari berbagai teknologi yang digunakan oleh aplikasi, Mule ESB memungkinkan integrasi aplikasi yang mudah, memungkinkan mereka untuk bertukar data. Pada bagian ini, kita akan membahas tentang konsep inti Mule yang berperan untuk mewujudkan integrasi tersebut.
Untuk ini, kita perlu memahami arsitekturnya serta blok bangunannya.
Arsitektur
Arsitektur Mule ESB memiliki tiga layer yaitu Transport layer, Integration layer dan Application layer seperti yang ditunjukkan pada diagram berikut -
Secara umum, ada tiga jenis tugas berikut yang dapat dilakukan untuk mengonfigurasi dan menyesuaikan penerapan Mule -
Pengembangan Komponen Layanan
Tugas ini melibatkan pengembangan atau penggunaan kembali POJO yang ada, atau Spring Beans. POJOs adalah kelas dengan atribut yang menghasilkan metode get dan set, konektor cloud. Di sisi lain, Spring Beans mengandung logika bisnis untuk memperkaya pesan.
Orkestrasi Layanan
Tugas ini pada dasarnya menyediakan mediasi layanan yang melibatkan konfigurasi prosesor pesan, router, transformer, dan filter.
Integrasi
Tugas terpenting Mule ESB adalah integrasi berbagai aplikasi terlepas dari protokol yang mereka gunakan. Untuk tujuan ini, Mule menyediakan metode transportasi yang memungkinkan penerimaan dan pengiriman pesan pada berbagai konektor protokol. Mule mendukung banyak metode transportasi yang ada, atau kami juga dapat menggunakan metode transportasi kustom.
Blok bangunan
Konfigurasi Mule memiliki blok penyusun berikut -
Kacang musim semi
Kegunaan utama Spring beans adalah untuk membangun komponen layanan. Setelah membuat komponen spring service, kita dapat mendefinisikannya melalui file konfigurasi atau secara manual, jika Anda tidak memiliki file konfigurasi.
Agen
Ini pada dasarnya adalah layanan yang dibuat di Anypoint Studio sebelum Mule Studio. Agen dibuat setelah Anda memulai server dan akan dihancurkan setelah Anda menghentikan server.
Penyambung
Ini adalah komponen perangkat lunak yang dikonfigurasi dengan parameter yang khusus untuk protokol. Ini terutama digunakan untuk mengontrol penggunaan protokol. Misalnya, konektor JMS dikonfigurasi dengan fileConnection dan konektor ini akan dibagikan di antara berbagai entitas yang bertanggung jawab atas komunikasi aktual.
Konfigurasi Global
Sesuai dengan namanya, blok penyusun ini digunakan untuk mengatur properti dan pengaturan global.
Titik Akhir Global
Ini dapat digunakan di tab Elemen Global yang dapat digunakan berkali-kali dalam aliran -
Prosesor Pesan Global
Sesuai namanya, ia mengamati atau mengubah pesan atau aliran pesan. Transformer dan filter adalah contoh dari Prosesor Pesan Global.
Transformers- Tugas utama transformator adalah mengubah data dari satu format ke format lainnya. Ini dapat didefinisikan secara global dan dapat digunakan dalam banyak aliran.
Filters- Filter inilah yang akan memutuskan pesan Mule mana yang harus diproses. Filter pada dasarnya menentukan kondisi yang harus dipenuhi agar pesan diproses dan diarahkan ke layanan.
Model
Berbeda dengan Agen, ini adalah pengelompokan logis dari layanan yang dibuat di studio. Kami memiliki kebebasan untuk memulai dan menghentikan semua layanan di dalam model tertentu.
Services- Layanan adalah salah satu yang membungkus logika atau komponen bisnis kami. Itu juga mengkonfigurasi Router, Endpoints, transformer dan filter khusus untuk layanan itu.
Endpoints- Ini dapat didefinisikan sebagai objek di mana layanan akan masuk (menerima) dan keluar (mengirim) pesan. Layanan terhubung melalui titik akhir.
Mengalir
Pengolah pesan menggunakan aliran untuk menentukan aliran pesan antara sumber dan target.
Struktur Pesan Mule
Pesan Mule, yang dibungkus seluruhnya di bawah Objek Pesan Mule, adalah data yang melewati aplikasi melalui aliran Mule. Struktur pesan Mule ditunjukkan pada diagram berikut -
Seperti yang terlihat pada diagram di atas, Mule Message terdiri dari dua bagian utama -
Header
Ini tidak lain adalah metadata pesan yang selanjutnya diwakili oleh dua properti berikut -
Inbound Properties- Ini adalah properti yang secara otomatis diatur oleh sumber pesan. Mereka tidak dapat dimanipulasi atau diatur oleh pengguna. Di alam, properti masuk tidak dapat diubah.
Outbound Properties- Ini adalah properti yang berisi metadata seperti properti masuk dan dapat disetel selama aliran. Mereka dapat diatur secara otomatis oleh Mule atau secara manual oleh pengguna. Secara alami, properti keluar bisa berubah.
Properti keluar menjadi properti masuk saat pesan diteruskan dari titik akhir keluar dari satu aliran ke titik akhir masuk aliran yang berbeda melalui pengangkutan.
Properti keluar tetap menjadi properti keluar saat pesan diteruskan ke aliran baru melalui flow-ref, bukan konektor.
Muatan
Pesan bisnis aktual yang dibawa oleh objek pesan disebut payload.
Variabel
Ini dapat didefinisikan sebagai metadata yang ditentukan pengguna tentang sebuah pesan. Pada dasarnya, variabel adalah bagian informasi sementara tentang pesan yang digunakan oleh aplikasi yang memprosesnya. Itu tidak dimaksudkan untuk diteruskan dengan pesan-pesan ke tujuannya. Mereka terdiri dari tiga jenis seperti yang diberikan di bawah ini -
Flow variables - Variabel ini hanya berlaku untuk aliran yang ada.
Session variables - Variabel ini berlaku di semua aliran dalam aplikasi yang sama.
Record variables - Variabel ini hanya berlaku untuk rekaman yang diproses sebagai bagian dari sebuah batch.
Lampiran dan Muatan Ekstra
Ini adalah beberapa metadata tambahan tentang muatan pesan yang tidak selalu muncul setiap kali di objek pesan.