Mengapa menggunakan layanan (REST / SOAP) alih-alih perpustakaan?

Katakanlah Anda ingin memecah aplikasi Anda menjadi layanan. Apakah ada alasan bagus untuk mengadopsi pendekatan SOA vs. hanya membuat API perpustakaan yang dapat dimuat oleh aplikasi yang membutuhkannya.

Perbedaannya mungkin halus di antara keduanya. Sebagai contoh di dunia .NET, Anda mungkin memiliki aplikasi yang akan terasa seperti monolitik bagi pengguna akhir dan yang akan bekerja pada mesin yang sama, tetapi di dalam, akan dipisahkan menjadi sekelompok layanan WCF. Anda mungkin juga memiliki arsitektur di mana perpustakaan tidak sangat terkait (addins / plugins) dan hanya mengikuti protokol ketika berbicara satu sama lain.

Jika kami menghindari membicarakan tentang kasus perantara tersebut, dan hanya berurusan dengan pustaka API yang tertaut kuat vs layanan REST terpisah, maka Anda mungkin ingin mempertimbangkan hal-hal berikut:

1. API perpustakaan dipanggil pada mesin yang sama. Layanan dapat di-host di mana saja dan dipanggil dari mana saja. Jika Anda menghitung hosting aplikasi pada beberapa mesin untuk alasan kinerja / skalabilitas / keamanan, kemungkinan Anda harus menggunakan layanan.

2. Situasinya mirip ketika menggunakan satu layanan oleh aplikasi yang digunakan pada beberapa mesin. Misalnya, jika Anda melakukan aplikasi untuk bank yang melakukan perhitungan finansial, salah satu caranya adalah dengan menyebarkan seluruh aplikasi besar ke setiap desktop, dan dipaksa untuk melakukan pembaruan ukuran besar untuk setiap klien setiap saat; pendekatan lain akan menjadi tuan rumah bagian komputasi pada server, dan menyebarkan ke desktop hanya aplikasi ringan hanya dengan UI dan banyak panggilan ke server tersebut.

3. Jika Anda meng-hosting layanan REST, siapa pun dapat menggunakannya: pengguna Mac, orang yang menggunakan Linux, dll. Jika Anda telah membuat pustaka C # dengan Visual Studio dan Anda mendistribusikannya sebagai DLL, lupakan pengguna (pelanggan) ?) yang tidak memiliki Windows.

Keuntungan lain dari layanan adalah bahwa ketika Anda memperbarui layanan, itu segera digunakan untuk semua konsumen layanan. Jadi, jika Anda memperbaiki bug, atau masalah kinerja, semua orang mendapat manfaat segera setelah layanan yang diperbarui ditayangkan, alih-alih harus mendistribusikan pembaruan yang orang mungkin memilih untuk mengabaikannya.

Keuntungan Perpustakaan:

• Overhead per panggilan yang lebih rendah (hanya melompat atau bahkan inline) ) = dapat meningkatkan kinerja
• Hal paling sederhana yang mungkin bisa berhasil
• Tidak ada risiko layanan terpusat turun dan berdampak pada semua konsumen

Keuntungan Layanan:

• Semua orang mendapat peningkatan segera dan transparan (kecuali API berversi yang ditawarkan)
• Konsumen tidak dapat mendekompilasi kode
• Dapat mengukur layanan perangkat keras secara terpisah
• Teknologi agnostik. Dengan perpustakaan bersama, konsumen harus memanfaatkan teknologi yang kompatibel.
• Lebih aman. Tingkat UI dapat memanggil layanan yang berada di belakang firewall alih-alih secara langsung mengakses DB.

Pendekatan SOA memungkinkan berbagai layanan untuk di-host dan dikelola secara terpisah. Selain kode, menggunakan layanan tertentu mungkin memerlukan banyak konfigurasi khusus (kata sandi, port, sertifikat, dll). Mengkonsumsi layanan REST memiliki kompleksitas yang terbatas yang dapat didokumentasikan dengan jelas dan mudah dipahami. Ini juga lebih aman karena itu berarti Anda tidak perlu memberikan akses ke DB atau sumber daya lainnya kepada klien.

Jika ada perubahan pada layanan SOA, maka layanan SOA itu harus dibangun kembali, diuji ulang dan dipekerjakan kembali. Semua aplikasi yang menggunakan layanan itu dapat terus melakukannya. Perubahan ke perpustakaan dalam DLL akan berarti semua konsumen perpustakaan itu harus dibangun kembali untuk referensi DLL itu, mereka semua harus diuji ulang dan mereka semua harus dipekerjakan kembali. Ada juga bahaya ini mungkin tidak terjadi dengan benar, dan aplikasi yang berbeda akan memiliki versi DLL yang berbeda. Kadang-kadang ini mungkin tidak menjadi masalah - mungkin setiap sistem harus memiliki versi perpustakaan yang hadir pada waktu penyebaran (Anda mungkin telah memperbarui sistem logging Anda untuk memiliki fitur-fitur baru yang bermanfaat - apakah Anda benar-benarperlu memperbarui setiap sistem dengan itu?) dalam hal ini perpustakaan baik-baik saja. Tetapi katakanlah Anda memiliki layanan untuk menghitung tarif pajak, dan undang-undang pajak berubah. Anda tidak ingin harus memperbarui setiap sistem untuk memasukkan perubahan ini, akan lebih baik melakukannya di satu tempat. Dalam hal ini layanan adalah pilihan yang lebih baik.

Ada beberapa jawaban yang baik tetapi saya ingin menambahkan lebih banyak hal ke jawaban yang diberikan:

Metode pustaka API sangat berguna ketika Anda ingin berinteraksi dengan hal-hal dengan sesedikit mungkin overhead. Konsekuensinya adalah bahwa ada sambungan yang lebih tinggi antara API dan aplikasi yang menggunakannya. Kadang-kadang, ini tidak apa-apa untuk aplikasi dan bahkan perlu, namun jika Anda memiliki sistem yang sangat terdistribusi atau Anda berpikir interoperabilitas adalah masalah besar, Anda mungkin perlu naik satu langkah abstraksi yang terakhir dan menggunakan cara komunikasi lainnya. Terutama, jika Anda ingin memiliki sistem terdistribusi, SOAP adalah jenis langkah selanjutnya dalam SOA, tetapi Anda akan tetap dibiarkan bergantung pada unit-unit tersebut, karena mereka harus mengetahui prosedur satu sama lain. REST membawanya ke tingkat yang baru, dengan memungkinkan mesin mempelajari sesuatu tentang konten di layanan lain dengan cara terpadu.

Dalam kasus Anda, jika aplikasi Anda tidak didistribusikan, saya tidak melihat alasan untuk mengubah aplikasi Anda menjadi SOA.