Apa itu arsitektur berorientasi layanan (SOA)?

SOA menghilangkan tugas-tugas dari pengembang aplikasi yang sebelumnya mengembangkan ulang atau menduplikasi fungsi-fungsi yang sudah ada atau harus mengetahui cara menghubungkan atau menyediakan interoperabilitas dengan fungsi-fungsi yang sudah ada.

Setiap layanan dalam SOA mewujudkan kode dan data yang diperlukan untuk menjalankan fungsi bisnis yang lengkap dan terpisah (misalnya memeriksa kredit pelanggan, menghitung pembayaran pinjaman bulanan, atau memproses aplikasi hipotek). Antarmuka layanan menyediakan keterikatan longgar. Ini berarti bahwa mereka dapat dipanggil dengan sedikit atau tanpa pengetahuan tentang bagaimana layanan diimplementasikan di bawahnya, sehingga mengurangi ketergantungan antar aplikasi.

Antarmuka ini adalah kontrak layanan antara penyedia layanan dan konsumen layanan. Aplikasi di balik antarmuka layanan dapat ditulis dalam Java, Microsoft.Net, Cobol atau bahasa pemrograman lainnya, disediakan sebagai aplikasi perangkat lunak paket oleh vendor (misalnya, SAP), aplikasi SaaS (misalnya, Salesforce CRM), atau diperoleh sebagai aplikasi sumber terbuka.

Antarmuka layanan sering kali didefinisikan dengan menggunakan bahasa definisi layanan web (WSDL) yang merupakan struktur tag standar berdasarkan xml (bahasa markup yang dapat diperluas).

Layanan diekspos dengan menggunakan protokol jaringan standar — seperti protokol akses objek sederhana (SOAP) /HTTP atau Restful HTTP (JSON/HTTP) —untuk mengirim permintaan untuk membaca atau mengubah data. Tata kelola layanan mengontrol siklus proses pengembangan dan pada tahap yang tepat, layanan dipublikasikan di registri yang memungkinkan pengembang dengan cepat menemukannya dan menggunakannya kembali untuk merakit aplikasi atau proses bisnis baru.

Layanan ini dapat dibangun dari awal tetapi sering kali dibuat dengan mengekspos fungsi dari sistem pencatatan lama sebagai antarmuka layanan.

Dengan cara ini, SOA mewakili tahap penting dalam evolusi pengembangan dan integrasi aplikasi selama beberapa dekade terakhir. Sebelum SOA muncul pada akhir 1990-an, menghubungkan aplikasi ke data atau fungsi yang ditempatkan di sistem lain memerlukan integrasi point-to-point yang kompleks — integrasi yang harus dibuat ulang oleh pengembang, sebagian atau keseluruhan, untuk setiap proyek pengembangan baru. Mengekspos fungsi-fungsi tersebut melalui layanan SOA memungkinkan pengembang untuk menggunakan kembali kemampuan yang sudah ada dan menghubungkannya melalui arsitektur SOA ESB (lihat di bawah).

Meskipun SOA, dan arsitektur layanan mikro yang lebih baru, memiliki banyak kata yang sama (yaitu “layanan” dan “arsitektur”), mereka hanya terkait secara longgar dan, pada kenyataannya, beroperasi pada cakupan yang berbeda, seperti yang dibahas nanti dalam artikel ini.

ESB , atau bus layanan perusahaan, adalah pola arsitektur dengan komponen perangkat lunak terpusat melakukan integrasi antara aplikasi. Ia melakukan transformasi model data, menangani konektivitas dan pengiriman pesan, melakukan perutean, mengonversi protokol komunikasi, dan berpotensi mengelola komposisi beberapa permintaan.

ESB dapat membuat integrasi dan transformasi ini tersedia sebagai antarmuka layanan untuk digunakan kembali oleh aplikasi baru. Pola ESB biasanya diimplementasikan dengan menggunakan integrasi waktu proses dan kumpulan alat yang membantu memastikan produktivitas terbaik.

Dimungkinkan untuk menerapkan SOA tanpa ESB, tetapi ini akan setara dengan hanya memiliki banyak layanan. Setiap pemilik aplikasi perlu terhubung langsung ke layanan apa pun yang dibutuhkan dan melakukan transformasi data yang diperlukan untuk memenuhi setiap antarmuka layanan.

Ini adalah pekerjaan yang berat (meskipun antarmuka dapat digunakan kembali) dan menciptakan tantangan pemeliharaan yang signifikan pada masa depan, karena setiap koneksi adalah titik ke titik. Faktanya, ESB pada akhirnya dianggap sebagai elemen de facto dari setiap implementasi SOA sehingga kedua istilah tersebut terkadang digunakan sebagai sinonim, menciptakan kebingungan.

Dibandingkan dengan arsitektur yang mendahuluinya, SOA menawarkan manfaat yang signifikan bagi perusahaan:

• Kelincahan bisnis yang lebih besar; penyiapan produk lebih cepat: Penggunaan kembali adalah kuncinya. Efisiensi merakit aplikasi dari layanan yang dapat digunakan kembali - yaitu, blok bangunan, daripada menulis ulang dan mengintegrasikan kembali dengan setiap proyek pengembangan baru, memungkinkan pengembang untuk membangun aplikasi dengan lebih cepat dalam menanggapi peluang bisnis baru.
  Pendekatan arsitektur berorientasi layanan mendukung skenario untuk integrasi aplikasi, integrasi data, dan otomatisasi gaya orkestrasi layanan dari proses bisnis atau alur kerja. Hal ini mempercepat desain perangkat lunak dan pengembangan perangkat lunak dengan memungkinkan pengembang menghabiskan lebih sedikit waktu untuk mengintegrasikan dan lebih banyak waktu untuk berfokus pada pengiriman dan peningkatan aplikasi mereka.
• Kemampuan untuk menggunakan fungsi-fungsi lama di pasar yang baru: SOA yang dibuat dengan baik memungkinkan pengembang untuk dengan mudah mengambil fungsi-fungsi yang 'terkunci' dalam satu platform atau lingkungan komputasi dan memperluasnya ke lingkungan dan pasar yang baru. Sebagai contoh, banyak perusahaan telah menggunakan SOA untuk mengekspos fungsi-fungsi dari sistem keuangan berbasis mainframe ke aplikasi web baru. Hal ini memungkinkan pelanggan mereka untuk melayani diri mereka sendiri untuk proses dan informasi yang sebelumnya hanya dapat diakses melalui interaksi langsung dengan karyawan atau mitra bisnis perusahaan.
• Peningkatan kolaborasi antara bisnis dan TI: Dalam SOA, layanan dapat didefinisikan dalam istilah bisnis (misalnya, 'menghasilkan kutipan asuransi' atau 'menghitung ROI peralatan modal'). Hal ini memungkinkan analis bisnis untuk bekerja lebih efektif dengan pengembang pada insight penting — seperti ruang lingkup proses bisnis yang ditentukan dengan menggunakan layanan atau implikasi bisnis dari mengubah proses — yang dapat mengarah pada hasil yang lebih baik.

Pada tahun 2010, implementasi SOA berjalan dengan tenaga penuh di perusahaan-perusahaan terkemuka di hampir setiap industri. Sebagai contoh:

Delaware Electric beralih ke SOA untuk mengintegrasikan sistem-sistem yang sebelumnya tidak bisa berbicara satu sama lain, sehingga menghasilkan efisiensi pengembangan yang membantu organisasi ini tetap bertahan selama lima tahun pembekuan tarif listrik yang diwajibkan oleh negara.

Cisco mengadopsi SOA untuk memastikan pengalaman pemesanan produknya konsisten di seluruh produk dan saluran dengan mengekspos proses pemesanan sebagai layanan yang dapat dimasukkan oleh divisi, akuisisi, dan mitra bisnis Cisco ke dalam situs web mereka.

Independence Blue Cross (IBC) of Philadelphia menerapkan SOA untuk membantu memastikan bahwa berbagai konstituen yang berurusan dengan data pasien - agen layanan pelanggan IBC, klinik dokter, pengguna situs web IBC - bekerja dengan sumber data yang sama ('sumber kebenaran tunggal').

Pakar telah mengisi beberapa ribu halaman cetak dan digital yang membandingkan SOA dan layanan mikro, dan mendefinisikan seluk-beluk hubungan mereka satu sama lain. Untuk tujuan artikel ini, perbedaan utama antara keduanya adalah penggabungan komponen dan ruang lingkup penggunaan:

SOA adalah gaya arsitektur integrasi dan konsep seluruh perusahaan. Hal ini memungkinkan aplikasi yang ada diekspos melalui antarmuka yang digabungkan secara longgar, masing-masing sesuai dengan fungsi bisnis yang memungkinkan aplikasi di satu bagian dari perusahaan yang diperluas untuk menggunakan kembali fungsi di aplikasi lain.

Arsitektur layanan mikro adalah gaya arsitektur aplikasi dan konsep cakupan aplikasi. Hal ini memungkinkan bagian dalam dari satu aplikasi dipecah menjadi beberapa bagian kecil yang dapat diubah, diskalakan, dan dikelola secara independen. Ini tidak mendefinisikan bagaimana aplikasi berbicara satu sama lain, untuk itu kita kembali ke lingkup perusahaan dari antarmuka layanan yang disediakan oleh SOA.

Layanan mikro muncul dan semakin populer seiring dengan munculnya virtualisasi, komputasi cloud, praktik pengembangan Agile, dan DevOps. Sebagian besar keuntungan layanan mikro dalam konteks ini muncul dari pemisahan komponen, yang menyederhanakan dan meningkatkan hal-hal berikut ini:

• Kelincahan dan produktivitas pengembang: Layanan mikro memungkinkan pengembang untuk menggabungkan teknologi baru ke satu bagian aplikasi tanpa memengaruhi sisa aplikasi. Setiap komponen dapat dimodifikasi, diuji, dan diterapkan secara independen dari yang lain, yang mempercepat siklus iterasi.
• Skalabilitas: Layanan mikro dapat memanfaatkan skalabilitas cloud secara maksimal — komponen apa pun dapat diskalakan secara independen dari yang lain untuk respons secepat mungkin terhadap tuntutan beban kerja dan penggunaan sumber daya komputasi yang paling efisien.
• Ketahanan: Sekali lagi, berkat pemisahan, kegagalan satu layanan mikro tidak berdampak pada layanan mikro lainnya. Dan setiap layanan mikro dapat bekerja sesuai dengan persyaratan ketersediaannya sendiri tanpa mempertaruhkan komponen lain atau seluruh aplikasi untuk memenuhi persyaratan ketersediaan umum.

Untuk mempelajari lebih dalam tentang perbedaan antara SOA dan layanan mikro, lihat SOA versus Layanan mikro: Apa bedanya?

Dengan cara yang sama bahwa arsitektur layanan mikro memiliki potensi untuk membawa peningkatan kelincahan, skalabilitas, dan ketahanan terhadap desain aplikasi, teknik yang sama ini juga dapat diterapkan pada integrasi.

Hal ini penting karena, seiring berjalannya waktu, pola ESB yang sangat tersentralisasi dan tim spesialis integrasi yang terpusat dapat menjadi hambatan. Dengan meminjam prinsip-prinsip layanan mikro, kami berpotensi memecah ESB menjadi integrasi yang lebih halus dan terdesentralisasi. Ini adalah salah satu premis inti di balik integrasi tangkas.