Arsitektur berorientasi layanan (SOA) adalah gaya arsitektur yang didasarkan pada gagasan bahwa layanan yang dapat dieksekusi dapat tertanam dalam aplikasi. Gagasan penting dibalik SOA adalah bahwa layanan yang sama dapat tersedia dari penyedia yang berbeda dan aplikasi dapat membuat keputusan pada saat runtime tentang penyedia layanan mana yang akan digunakan. Pemohon layanan (terkadang disebut klien layanan) yang ingin menggunakan layanan mencari spesifikasi layanan tersebut dan menemukan penyedia layanan.
Standar UDDI (Deskripsi Universal, Penemuan, dan Integrasi) mendefinisikan komponen spesifikasi layanan yang dimaksudkan untuk membantu calon pengguna menemukan keberadaan layanan. Standar ini dimaksudkan untuk memungkinkan perusahaan mengatur registrasi, dengan deskripsi UDDI yang menjelaskan layanan yang mereka tawarkan. Layanan penerima mem-parsing pesan, melakukan penghitungan dan, setelah kompilasi, mengirimkan respons dalam bentuk pesan ke layanan yang meminta.
Detail ini disediakan dalam deskripsi layanan yang ditulis dalam bahasa berbasis XML yang disebut WSDL (Web Service Description Language).
Service Components in an SOA (Lanj.)
Bagian "apa" dari dokumen WSDL, yang disebut antarmuka, menentukan operasi mana yang didukung layanan dan menentukan format pesan yang dikirim dan diterima oleh layanan. Bagian pengantar yang biasanya mendefinisikan namespace XML yang digunakan dan mungkin menyertakan bagian dokumentasi yang memberikan informasi tambahan tentang layanan. Penjelasan mengenai binding yang digunakan oleh layanan, yaitu protokol pengiriman pesan yang akan digunakan untuk mengirim dan menerima pesan.
Pengikatan menentukan bagaimana pesan masukan dan keluaran terkait layanan harus dikemas menjadi pesan, dan menentukan protokol komunikasi yang digunakan. Pesan masukan juga menentukan apakah suhu ini akan dikembalikan dalam derajat Celsius atau derajat Fahrenheit. Operasi we atherInfo memiliki pola masuk-keluar terkait yang berarti bahwa operasi ini mengambil satu pesan masukan dan menghasilkan satu pesan keluaran.
Selanjutnya, pesan masukan dan keluaran ditentukan, mengacu pada definisi yang dibuat sebelumnya di bagian tipe.
RESTful Services
RESTful Services
Service Engineering
Rekayasa layanan adalah proses pengembangan layanan untuk digunakan kembali dalam aplikasi berorientasi layanan. Insinyur layanan harus memastikan bahwa layanan mewakili abstraksi yang dapat digunakan kembali dan dapat digunakan dalam sistem yang berbeda.
Service Engineering
Service Candidate Identification
Utilitas: Layanan ini mengimplementasikan beberapa fungsi umum yang dapat digunakan oleh berbagai proses bisnis. Contoh utilitasnya adalah layanan konversi mata uang yang dapat diakses untuk menghitung konversi suatu mata uang (misalnya dolar) ke mata uang lain.
Service Candidate Identification (Lanj.)
Layanan koordinasi atau proses: Layanan ini mendukung proses bisnis yang lebih umum yang biasanya melibatkan berbagai aktor dan aktivitas. Contoh jasa koordinasi dalam suatu perusahaan adalah jasa pemesanan yang memungkinkan dilakukannya pemesanan kepada pemasok, penerimaan barang, dan pembayaran. Layanan berorientasi tugas dikaitkan dengan aktivitas tertentu, sedangkan layanan berorientasi entitas dikaitkan dengan sumber daya sistem.
Tujuan dalam mengidentifikasi calon layanan adalah untuk mengidentifikasi layanan yang koheren secara logis, independen, dan dapat digunakan kembali. Dalam hal ini, klasifikasi Erle berguna karena menyarankan cara menemukan layanan yang dapat digunakan kembali dengan memandang entitas bisnis sebagai sumber daya dan aktivitas bisnis. Penting untuk memikirkan kandidat yang mungkin dan kemudian mengajukan serangkaian pertanyaan tentang mereka untuk menentukan apakah mereka dapat menjadi layanan yang berguna.
Untuk layanan berorientasi entitas, layanan terkait dengan sumber daya logis tunggal yang digunakan dalam proses bisnis berbeda. Untuk layanan berorientasi tugas, apakah tugas tersebut dilakukan oleh orang yang berbeda dalam organisasi. Misalnya, layanan berorientasi entitas yang terkait dengan katalog mungkin tersedia untuk pengguna internal dan eksternal.
Hasil dari proses pemilihan layanan adalah serangkaian layanan yang teridentifikasi dan persyaratan terkait untuk layanan tersebut. Untuk memfasilitasi pemesanan otomatis, perusahaan ingin membuat layanan katalog yang memungkinkan pelanggan memilih peralatan yang mereka butuhkan. Sebaliknya, barang dipesan melalui sistem pengadaan online dari masing-masing perusahaan yang mengakses katalog sebagai layanan online.
Hal ini harus mencakup konfigurasi dan peralatan yang disepakati yang dapat dipesan oleh karyawan perusahaan pelanggan dan harga peralatan yang telah disepakati dengan perusahaan tersebut. Pengguna katalog harus dapat melakukan "pesanan virtual" di mana barang yang diminta akan disimpan selama 48 jam.
Desain Antarmuka Layanan
Jika layanan RESTful digunakan, pertimbangan harus diberikan pada sumber daya yang diperlukan dan bagaimana operasi standar harus digunakan untuk menjalankan operasi layanan.
Desain Antarmuka Layanan (Lanj.)
Jika Anda memilih pendekatan berbasis SOAP, Anda harus merancang struktur pesan XML yang dikirim dan diterima oleh layanan. Setelah membuat deskripsi informal tentang apa yang harus dilakukan oleh layanan, langkah selanjutnya adalah menambahkan lebih banyak detail tentang input dan output layanan, seperti pada Gambar 13.11, yang memperluas deskripsi fungsional pada Gambar 13.10. Secara umum, merupakan praktik yang baik ketika mengembangkan komponen yang dapat digunakan kembali untuk menyerahkan semua penanganan pengecualian kepada pengguna komponen tersebut.
Namun terkadang, diperlukan desain yang lebih detail, dan deskripsi detail antarmuka dapat ditentukan dalam notasi grafis seperti UML atau dalam format deskripsi yang dapat dibaca manusia seperti JSON. Layanan katalog adalah contoh layanan praktis, yang menggambarkan bahwa tidak selalu jelas apakah akan memilih pendekatan berbasis RESTful atau SOAP dalam implementasi layanan. Sebagai layanan berbasis entitas, katalog dapat direpresentasikan sebagai sumber daya, yang menunjukkan bahwa model RESTful adalah model yang tepat untuk digunakan.
Namun, operasi pada katalog bukanlah operasi AAO sederhana, dan memerlukan keadaan tertentu dipertahankan dalam sesi interaksi dengan katalog. Dilema seperti ini biasa terjadi dalam rekayasa jasa, dan biasanya keadaan lokal (misalnya ketersediaan keahlian) merupakan faktor utama dalam memutuskan pendekatan mana yang akan digunakan. Untuk mengimplementasikan serangkaian layanan RESTful, seseorang harus memutuskan kumpulan sumber daya yang akan digunakan untuk mewakili katalog dan bagaimana operasi dasar AOO, POST, dan PUT akan bekerja pada sumber daya ini.
Itu harus memiliki URL dalam bentuk
Untuk layanan berbasis SOAP, proses realisasinya lebih sederhana dalam hal ini karena desain antarmuka logis dapat diterjemahkan secara otomatis ke WSDL. Kebanyakan lingkungan pemrograman yang mendukung pengembangan berorientasi layanan (misalnya lingkungan ECLIPSE) menyertakan alat yang dapat menerjemahkan deskripsi antarmuka logis ke dalam representasi WSDL yang sesuai.
Implementasi dan Penyebaran Layanan
Implementasi dan Penyebaran Layanan (Lanj.)
Alternatifnya, ia dapat mengimplementasikan layanan dengan membuat antarmuka layanan untuk komponen yang ada atau sistem lama. Oleh karena itu, aset perangkat lunak yang telah terbukti bermanfaat dapat tersedia untuk digunakan kembali. Untuk layanan berbasis SOAP, tersedia alat pengujian yang memungkinkan layanan diperiksa dan diuji dan menghasilkan pengujian dari spesifikasi WSDL.
Jika layanan dimaksudkan untuk tersedia dalam organisasi besar atau sebagai layanan yang tersedia untuk umum, layanan tersebut harus menyediakan dokumentasi untuk pengguna eksternal layanan tersebut. Pengguna potensial kemudian dapat memutuskan apakah layanan tersebut dapat memenuhi kebutuhan mereka, untuk memberikan layanan yang andal dan aman.
Service Composition
Service Composition
Desain & Implementasi Alur Kerja
Desain alur kerja melibatkan analisis proses bisnis yang ada atau yang direncanakan untuk memahami tugas-tugas yang terlibat dan bagaimana tugas-tugas tersebut bertukar informasi. Ini mendefinisikan tahapan yang terlibat dalam pelaksanaan suatu proses dan informasi yang ditransfer antara berbagai tahapan proses.
Desain & Implementasi Alur Kerja (Lanj.)
Mereka adalah model grafis yang ditulis menggunakan diagram aktivitas UML atau BPMN, Notasi Pemodelan Proses Bisnis. Lingkaran terang digunakan untuk mewakili peristiwa awal dan lingkaran gelap digunakan untuk mewakili peristiwa akhir. Peristiwa dapat berupa peristiwa jam yang memungkinkan alur kerja berjalan secara berkala atau batas waktu.
Dalam contoh ini, alur kerja untuk layanan SetupComputation meminta akses ke prosesor vektor dan, jika prosesor tersedia, menetapkan komputasi yang diperlukan dan mengunduh data ke layanan pemrosesan. Diwakili secara grafis dengan melampirkan alur kerja setiap peserta proses dalam bentuk persegi panjang, dengan nama ditulis secara vertikal di tepi kiri. Seperti yang saya sarankan dalam pembahasan Gambar 13.14, model dapat melalui beberapa iterasi hingga tercipta desain yang memungkinkan penggunaan kembali layanan yang tersedia semaksimal mungkin.
Hal ini melibatkan penerapan layanan siap pakai untuk digunakan kembali dan mengubah model alur kerja menjadi program yang dapat dijalankan. Model alur kerja dapat diproses secara otomatis untuk membuat model WS-BPEL yang dapat dieksekusi jika layanan berbasis SOAP digunakan. Alternatifnya, jika layanan RESTful digunakan, alur kerja dapat diprogram secara manual, dengan model bertindak sebagai spesifikasi aplikasi.
Menguji Komponen Layanan
Menguji Komponen Layanan (Lanj.)
Penyedia layanan dapat menarik atau mengubah layanan ini kapan saja, sehingga pengujian aplikasi sebelumnya tidak valid. Masalah ini diatasi dalam komponen perangkat lunak dengan mempertahankan versi komponen yang berbeda, namun versi layanan biasanya tidak didukung. Jika layanan terikat secara dinamis, aplikasi mungkin tidak selalu menggunakan layanan yang sama setiap kali dijalankan.
Perilaku non-fungsional suatu layanan tidak hanya bergantung pada bagaimana layanan tersebut digunakan oleh aplikasi yang diuji. Suatu layanan dapat bekerja dengan baik selama pengujian karena tidak berjalan di bawah beban yang berat. Dalam praktiknya, perilaku layanan yang diamati mungkin berbeda-beda karena permintaan yang dibuat oleh pengguna layanan lain.
Terdapat beberapa model pembayaran yang berbeda: Beberapa layanan mungkin tersedia secara gratis, beberapa mungkin dibayar dengan berlangganan, dan yang lainnya mungkin dibayar untuk penggunaan. Jika layanannya gratis, maka penyedia layanan tidak ingin dikenakan biaya oleh aplikasi uji coba; jika langganan diperlukan, maka pengguna layanan mungkin enggan untuk membuat perjanjian berlangganan sebelum menguji layanan tersebut. Demikian pula, jika penggunaan didasarkan pada pembayaran per penggunaan, pengguna layanan mungkin menganggap biaya pengujian terlalu mahal.
Ada kesulitan dalam menguji tindakan tersebut karena tindakan tersebut mungkin bergantung pada kegagalan layanan lain.
Ringkasan
Ringkasan (Lanj.)
Sebagai alternatif, arsitektur RESTful dapat digunakan, yang didasarkan pada sumber daya standar dan operasi pada sumber daya tersebut. Pendekatan RESTful menggunakan protokol http dan https untuk komunikasi layanan dan memetakan operasi ke kata kerja http standar POST, GET, PUT, dan DELETE. Proses rekayasa layanan mencakup mengidentifikasi kandidat layanan untuk implementasi, menentukan antarmuka layanan, dan menerapkan, menguji, dan menerapkan layanan.
Pengembangan perangkat lunak menggunakan layanan didasarkan pada gagasan bahwa program dibuat dengan mengkompilasi dan mengkonfigurasi layanan untuk menciptakan layanan dan sistem gabungan baru.
Studi Kasus
TERIMA KASIH
