Apa itu arsitektur berorientasi layanan?

Arsitektur berorientasi layanan (SOA) muncul pada awal abad ini sebagai evolusi komputasi terdistribusi. Sebelum SOA, layanan dipahami sebagai hasil akhir dari proses pengembangan aplikasi. Dalam SOA, aplikasi itu sendiri terdiri dari layanan. Layanan dapat disampaikan secara individual atau digabungkan sebagai komponen dalam layanan gabungan yang lebih besar.

Layanan berinteraksi melalui kabel menggunakan protokol seperti REST atau SOAP (Simple Object Access Protocol). Layanan digabungkan secara longgar , yang berarti antarmuka layanan tidak bergantung pada implementasi yang mendasarinya. Pengembang atau integrator sistem dapat membuat satu atau lebih layanan ke dalam aplikasi tanpa harus mengetahui bagaimana setiap layanan diimplementasikan.

Artikel ini adalah gambaran umum Java SOA dan karakteristik utama dari arsitektur berorientasi layanan yang diimplementasikan menggunakan layanan web berbasis SOAP. Saya juga akan secara singkat membandingkan SOA dan layanan mikro dan membahas perbedaan antara layanan web berbasis RESTful dan SOAP di Java.

SOA dan layanan web

SOA dan layanan web sering kali digabungkan, tetapi keduanya bukan hal yang sama. SOA adalah arsitektur yang memungkinkan pengembang menggabungkan beberapa layanan aplikasi menjadi layanan gabungan yang lebih besar. SOA dapat diimplementasikan menggunakan layanan web berbasis SOAP atau REST API, atau terkadang kombinasi keduanya. Penting untuk dipahami bahwa dalam SOA, layanan adalah sumber daya yang tersedia dari jarak jauh yang dapat menanggapi permintaan. Layanan web diimplementasikan menggunakan protokol tertentu.

Mengapa arsitektur berorientasi layanan?

SOA mengatasi tiga tantangan umum perusahaan:

  • Tanggapi dengan cepat perubahan bisnis.
  • Memanfaatkan investasi infrastruktur yang ada.
  • Mendukung saluran interaksi baru dengan pelanggan, mitra, dan pemasok.

Infrastruktur perusahaan bersifat heterogen di seluruh sistem operasi, aplikasi, perangkat lunak sistem, dan infrastruktur aplikasi. Akibatnya, banyak sistem perusahaan terdiri dari aplikasi yang kompleks dan tidak konsisten yang memberikan berbagai layanan yang saling bergantung. Aplikasi yang ada yang menjalankan proses bisnis saat ini sangat penting, jadi memulai dari awal atau memodifikasinya adalah proposisi yang rumit. Tetapi perusahaan harus dapat memodifikasi dan memperluas infrastruktur teknis untuk memenuhi tuntutan bisnis.

SOA dan layanan mikro

Layanan mikro adalah gaya arsitektur yang dikembangkan dari SOA. Keduanya adalah arsitektur terdistribusi dan keduanya menawarkan paradigma terpisah. Sementara arsitektur berorientasi layanan lebih berat pada infrastruktur, layanan mikro menawarkan gaya pengembangan yang lebih fleksibel dan ringan. Ada pro dan kontra untuk keduanya, dan keduanya banyak digunakan. Secara umum, SOA lebih sering diimplementasikan atau dipelihara oleh perusahaan mapan yang memiliki sumber daya untuk mendukung lebih banyak formalitas. Layanan mikro sering kali menarik bagi organisasi baru atau berkembang yang membutuhkan ketangkasan.

Dibandingkan dengan arsitektur monolitik, sifat SOA yang digabungkan secara longgar membuatnya relatif mulus untuk menyambungkan layanan baru atau meningkatkan layanan yang ada untuk kebutuhan bisnis baru. Ini juga memberikan opsi untuk membuat layanan dapat dikonsumsi di berbagai saluran, dan untuk mengekspos aplikasi lama sebagai layanan, dengan demikian melindungi investasi infrastruktur.

Karena mereka digabungkan secara longgar, komponen SOA dapat diubah dengan dampak minimal ke komponen lain. Komponen juga dapat ditambahkan ke arsitektur dengan cara standar, dan dapat diskalakan untuk mengatasi beban.

Sebagai contoh, pertimbangkan bagaimana suatu perusahaan dapat menggunakan sekumpulan aplikasi yang ada untuk membuat aplikasi rantai pasokan komposit yang baru. Sementara aplikasi yang ada bersifat heterogen dan tersebar di berbagai sistem, fungsinya diekspos dan diakses menggunakan antarmuka standar.

Matthew Tyson

Karakteristik utama SOA

SOA dapat sesederhana layanan konsumsi komponen tunggal yang disediakan oleh komponen lain atau secanggih berbagai komponen yang berinteraksi melalui bus layanan perusahaan seperti ESB MuleSoft. Tidak peduli apa skalanya, kunci keberhasilan implementasi SOA adalah menggunakan kerumitan sesedikit mungkin untuk mencapai tujuan Anda. Pertanyaan pertama dan terakhir Anda harus selalu: Apakah desain ini memenuhi persyaratan bisnis kita?

Terlepas dari skala atau kompleksitas, pola arsitektur berorientasi layanan kurang lebih sama:

  • Penyedia layanan memaparkan titik akhir dan menjelaskan tindakan yang tersedia di setiap titik akhir.
  • Konsumen layanan mengeluarkan permintaan dan mengkonsumsi tanggapan.
  • Penyedia layanan menghasilkan pesan untuk menangani permintaan.

Menerapkan arsitektur berorientasi layanan

Untuk mengimplementasikan SOA Anda mulai dengan arsitektur layanan dasar, kemudian menyediakan infrastruktur, yang berarti protokol dan alat lain yang memungkinkan komunikasi dan interoperabilitas. Gambar 2 menunjukkan diagram arsitektur layanan yang khas.

Matthew Tyson

Dalam diagram ini, tiga konsumen meminta layanan dengan mengirimkan pesan ke bus layanan perusahaan, yang mengubah dan merutekan pesan ke implementasi layanan yang sesuai. Sebuah mesin aturan bisnis menggabungkan aturan bisnis dalam layanan atau seluruh layanan. Sebuah lapisan manajemen pelayanan mengelola kegiatan seperti audit, penagihan, dan penebangan.

Komponen dalam arsitektur ini digabungkan secara longgar, sehingga dapat dialihkan atau diperbarui dengan dampak yang relatif minimal terhadap aplikasi secara keseluruhan. Ini memberikan fleksibilitas perusahaan untuk menambah atau memperbarui proses bisnis sesuai kebutuhan. Sebagian besar, perubahan pada layanan individu seharusnya tidak terlalu memengaruhi layanan lain.

SOAP vs layanan web RESTful

Dimungkinkan untuk mengadopsi gaya SOA dan mengimplementasikannya dengan REST, misalnya menggunakan JAX-RS API atau Spring Boot Actuator, tetapi pembahasan itu di luar cakupan untuk artikel ini. Lihat "SOAP vs REST vs JSON" untuk perbandingan yang berguna antara layanan web SOAP vs RESTful. Ada juga beberapa tumpang tindih antara layanan web RESTful dan gaya yang lebih ringan yang terkait dengan layanan mikro.

Layanan web berbasis SOAP

Layanan web yang diimplementasikan menggunakan SOAP masih lebih kaku daripada layanan web RESTful atau implementasi layanan mikro, tetapi jauh lebih fleksibel daripada hari-hari awal SOA. Di sini kita hanya akan melihat protokol tingkat tinggi yang diperlukan untuk layanan web berbasis SOAP.

SOAP, WSDL, dan XSD

SOAP, WSDL, dan XSD adalah infrastruktur dasar dari implementasi layanan web berbasis SOAP. WSDL digunakan untuk menggambarkan layanan, dan SOAP adalah lapisan transport untuk mengirim pesan antara konsumen dan penyedia layanan. Layanan berkomunikasi dengan pesan yang ditentukan secara formal menggunakan XML Schema (XSD). Anda dapat menganggap WSDL sebagai antarmuka layanan (analog dengan antarmuka Java). Implementasinya dilakukan di kelas Java, dan komunikasi melalui jaringan terjadi melalui SOAP. Secara fungsional, konsumen akan mencari layanan, mendapatkan WSDL untuk layanan tersebut, kemudian menjalankan layanan menggunakan SOAP.

Keamanan layanan web

Spesifikasi WS-I Basic Profile 2.0 membahas keamanan pesan. Spesifikasi ini berfokus pada pertukaran kredensial, integritas pesan, dan kerahasiaan pesan.

Penemuan layanan web

Setelah menjadi landasan penemuan layanan web, UDDI (Deskripsi Universal, Definisi, dan Integrasi) telah memudar menjadi sejarah. Hari ini adalah umum untuk mengekspos layanan web berbasis SOAP seperti yang Anda lakukan pada layanan lain, melalui URL titik akhir. Sebagai contoh, Anda dapat menggunakan JAX-WS Service Endpoint Interface @WebServicedan @WebMethodpenjelasannya.

Membangun dan menerapkan layanan web

Pengembang Java memiliki beberapa opsi untuk membangun dan menyebarkan layanan web berbasis SOAP, termasuk Apache Axis2 dan Spring-WS; namun, standar Java adalah JAX-WS, Java API untuk XML Web Services. Ide inti di balik JAX-WS adalah untuk membuat kelas Java dan memberi anotasi pada mereka untuk membuat artefak yang diperlukan. Di bawah tenda, JAX-WS menggunakan beberapa paket Java, termasuk JAXB, perpustakaan tujuan umum untuk mengikat kelas Java ke XML.

JAX-WS menyembunyikan kompleksitas dan protokol yang mendasari dari pengembang, sehingga mempersingkat proses pendefinisian dan penyebaran layanan SOAP berbasis Java. IDE Java modern seperti Eclipse menyertakan dukungan penuh untuk mengembangkan layanan web JAX-WS. Spesifikasi JAX-WS juga telah dipilih untuk pengembangan yang sedang berlangsung di Jakarta EE.

Kesimpulan

Arsitektur berorientasi layanan yang diimplementasikan dengan layanan web berbasis SOAP membutuhkan definisi layanan yang lebih kaku dan formal daripada layanan web atau layanan mikro RESTful. Namun, beberapa organisasi yang lebih besar terus mendukung gaya yang lebih formal yang diberlakukan oleh SOAP. Banyak sistem warisan skala besar juga dibangun di atas SOAP, dan beberapa B2B dan sistem internal memilih layanan web berbasis SOAP untuk kontrak API yang lebih formal. Apakah Anda sedang mengembangkan atau memelihara sistem perusahaan skala besar, memahami pola SOA dan mampu mengevaluasi pilihan Anda untuk menerapkannya akan membantu Anda dengan baik dalam karir pemrograman Anda.

Cerita ini, "Apa itu arsitektur berorientasi layanan?" awalnya diterbitkan oleh JavaWorld.