Salah satu prinsip desain layanan SOA utama adalah prinsip Kompabilitas Layanan ( https://en.wikipedia.org/wiki/Service_composability_principle ).
Idenya adalah bahwa dengan menyusun layanan baru menggunakan yang sudah ada sebagai blok bangunan, seseorang dapat dengan cepat mengembangkan layanan baru. Jenis analog dengan bagaimana Anda memanggil metode objek yang ada ketika Anda menerapkan metode baru. Di sinilah banyak dorongan produktivitas dari SOA seharusnya berasal.
Apakah seseorang benar-benar melakukan ini dalam praktik? Saya telah melihat ini berulang tanpa henti dalam teks tertulis, tetapi belum mengalami implementasi dunia nyata yang bekerja sendiri. Sebagian besar teks juga menghilangkan menyebutkan penanganan transaksi , yang menurut saya menjadi hambatan terbesar dalam mewujudkan layanan yang dapat dikomposit.
Pertama, Anda benar-benar perlu mengatasi masalah transaksi sebelum Anda dapat membuat layanan non-sepele. Tentu, jika contoh memiliki layanan "findCurrentTime ()" dan "writeLogMessage ()" mudah untuk tidak khawatir tentang transaksi, tetapi tidak ketika memiliki contoh dunia nyata seperti "depositMoney ()" dan "withdrawMoney ()".
Saya tahu dua opsi:
- Terapkan transaksi nyata dengan Transaksi WS-Atomic atau semacamnya
- Terapkan solusi berbasis kompensasi yang mengkompensasi panggilan ke A dengan "cancelA ()" atau semacamnya jika panggilan ke B gagal
Kedua hal ini tampaknya sangat bermasalah / hampir tidak dapat digunakan oleh saya:
- Transaksi WS-Atomic
- a banyak kompleksitas, paling saran yang saya temukan hanya memperingatkan "rasa sakit di pantat, dont melakukannya"
- dukungan terbatas, misalnya jika Anda mengambil ESB open source, alternatif utama ServiceMix, Mule atau WSO2 tidak mendukungnya
- kompensasi
- menerapkan penanganan kompensasi tampaknya sangat rumit bagi saya. Apa yang kita lakukan jika layanan A berhasil dan kita tidak pernah mendapatkan jawaban dari layanan B dan tidak tahu apakah itu gagal atau berhasil? Menangani logika semacam itu secara manual (sebagai implementor layanan pengomposisian) membuat saya ingin memotong pergelangan tangan saya - ini adalah jenis pekerjaan yang harus dilakukan beberapa alat bagi saya !.
- Saya juga tidak melihat bagaimana Anda dapat memiliki metode kompensasi dalam layanan non-sepele. Katakanlah layanan Anda A adalah "depositMoney ()" dan itu berhasil, beberapa tindakan lain dengan cepat mentransfer uang di tempat lain, dan kemudian kami menerima "kompensasiDepositMoney ()", apa yang kita lakukan sekarang? Sepertinya kaleng besar cacing.
Bagi saya sepertinya komposisi layanan adalah prinsip SOA yang mendasar sehingga Anda benar-benar tidak mendapatkan manfaat dari SOA jika Anda tidak dapat (dengan mudah) membuat layanan . Apa kenyataannya? 90% pengguna SOA menggunakan "criplled SOA" tanpa layanan yang sebenarnya? Atau sebagian besar pengguna memang menggunakan komposisi layanan dan saya melebih-lebihkan kesulitannya?