Evaluasi Komunikasi antar-Services & Eksekusi Transaksi-transaksi

dalam Arsitektur RESTful dan WS-*Oleh

Raden Arum Setia Priadi

D053182003

Manage the complex behaviors of modern microservice architectures

Latar Belakang

• Tujuan dari pemakaian microservices, untuk menggunakan unit otonom yang terisolasi satu darilainnya dan mengkoordinasikan mereka ke dalam infrastruktur terdistribusi oleh teknologi container ringan, seperti Docker. Biasanya, adopsi model arsitektur ini menyiratkan juga keperluanmengadopsi praktik lincah, seperti DevOps, yang mengurangi waktu antara menerapkan perubahansistem dan mentransfer perubahan ini ke lingkungan produksi [Aderaldo et al. 2017].

• Ada banyak manfaat penggunaan microservices, seperti keragaman teknologi dalam satu sistem, skalabilitas yang lebih baik, meningkatkan produktivitas, dan kemudahan penyebaran [Alshuqayranet al. 2016, Newman 2015]. Oleh karena itu, manfaat ini dapat meningkatkan keterpeliharaanperangkat lunak [Alshuqayran et al. 2016].

• Namun, microservices juga memiliki kekurangan. Biasanya, layanan yang menyusun perangkatlunak adalah bagian dari distributed setting. Oleh karena itu, microservices dapat mempersulitbeberapa tugas seperti: 1) menemukan layanan dalam jaringan [finding a service within thenetwork], 2) mengelola keamanan, 3) mengeksekusi transaksi, dan 4) mengoptimalkan komunikasiantara services [Alshuqayran et al. 2016, Yu et al. 2016].

• Bagai mana respons pengembang, diperlukan: 1) Pengalamanan pengembangan, 2) Pengalamanmicroservices, 3) Peran pengembang ybs [back-end developer, DevOps Specialist, Software architect, User-experience designer].

Tugas ke-4 (Optimalisasi Komunikasi Antar-service)• Pada micro-services setiap fitur dibangun terpisah dan independen dari semua fitur lainnya, focus

mengerjakan satu pekerjaan dengan baik. Untuk komunikasi antar-service digunakan HTTP restatau message bus. Komunikasi antar-service biasanya melalui network call. Terlihat jauh lebihkompleks dan lebih banyak usaha dalam pengembangannya.

• Remote Procedure Invocation (RPI). Misalnya Order Service membutuhkan Data Product dariProduct Service. Di sini pentingnya komunikasi antar service misalnya: RPI atau RPC (Remote Procedure Call), membuat API (call). Tidak direkomendasi komunikasi via basis data. Contoh RPI yaitu: 1) RESTful API [http], 2) gRPC, 3) Apache Thrift, 4) SOAP [Simple Object Access Protocol], 5) Java RMI [Remote Method Invocation], 6) Corba [Common Object Request Broker Architecture].

• Untuk implementasi ke web, android, iOS, dll tidak bisa secara langsung. Kita harus membuatterlebih dahulu yang namanya API Gateway: API ini memiliki tugas seperti load balancing, caching, access controll , API metering, dan monitoring. API Gateway: Bagai mana cara meng-ekspos micro services yang aman? User mengakses micro services melalui internet. Masalah-masalah meng-ekspos tersebut: 1) Semua service bisa diakses dari luar, 2) Jika butuh autentikasi, harusdiimplementasi di semua service, 3) Rawan terjadi kebocoran data.

Tugas ke-4

• API Gateway adalah aplikasi yang bertugas sebagai gerbang dari luar (akses dariinternet) ke dalam (aplikasi micro services), sebagai proxy server ke semua aplikasi micro services. Jadi aplikasi micro services hanya bisa diakses dari luar melalui API Gateway.Contoh API Gateway: a] Nginx, b] Apache HTTP, c] Kong, d] Netflix Zuul, e] Spring Cloud Gateway.

• Tipe-tipe micro services terdiri atas: 1) Stateless micro service [E-mail /SMS services], 2) Persistence micro service [CS /Product /Order services], 3) Aggregation micro service➔ Pattern Service Orchestration [dari Product service → Cart service → Order service → hingga Payment service].

• Micro services berangkat dari rute ESB (Enterprise Service Bus) tradisional untukmengadopsi layanan API Gateway. Dalam micro services, setiap layanan menggunakanAPI untuk mengekspos dirinya ke layanan lain dan konsumen. API layanan initerdesentralisasi, tidak seperti di ESB, namun masih memerlukan pemantauan untukmemahami jika API berkomunikasi secara efektif dengan sisa layanan yang berjalandalam kontainer. Jika tidak, API menjadi blind spot dalam memonitor micro services Anda.

Tugas ke-3 (Meng-eksekusi Transaksi)

• Pemantauan container melibatkan pelacakan setiap bagian dari sistem, termasuk mesin kontainer, registry, gambar yang di-download, contoh kontainer yang dibuat dan pensiun, volume penyimpanan yang ditetapkan secara dinamis untuk kontainer, permintaan jaringan antarakontainer, keamanan dan kontrol akses dan banyak lagi. Containers membawa visibilitas mendalamke setiap langkah dari pembangunan pipa, dan mereka melibatkan berbagai metrik yang lebih luasuntuk melacak, tetapi mereka juga memberikan kemungkinan pengembangan dan pengiriman fiturjauh lebih cepat dari pada SOA.

• Meskipun tidak ada pendekatan tunggal yang cocok untuk semua, aplikasi cloud biasanyamenggunakan data yang tersebar di seluruh penyimpanan data. Mengelola dan memeliharakonsistensi data dalam lingkungan ini dapat menjadi aspek penting dari sistem, terutama dalam halmasalah konkurensi dan ketersediaan yang dapat muncul. Anda perlu memperdagangkankonsistensi yang kuat untuk ketersediaan. Ini berarti bahwa Anda mungkin perlu merancangbeberapa aspek aplikasi di sekitar gagasan konsistensi akhirnya dan menerima bahwa data yang digunakan aplikasi Anda mungkin tidak sepenuhnya konsisten sepanjang waktu.

Tugas ke-3

• Micro services baru-baru ini muncul sebagai gaya arsitektur, membahas bagaimana membangun, mengelola, dan berevolusi arsitektur dari kecil, unit mandiri. Terutama di cloud, pendekatanarsitektur layanan mikro tampaknya menjadi pelengkap yang ideal dari teknologi kontainer di tingkat PaaS. Namun, saat ini tidak ada studi sekunder untuk mengkonsolidasikan penelitian ini.

• Cloud menyediakan alat manajemen untuk jadwal penyebaran yang fleksibel dan penyediaankebutuhan orkestrasi, khususnya, jika ini harus disediakan PaaS. Riset mengenai layanan mikrotelah membahas prinsip dan dukungan arsitektural serta penerapan pola arsitektural di awan. Dalam awan, Layanan mikro dihubungkan ke kontainer, yang merupakan mekanisme virtualisasiringan yang digunakan untuk pengemasan aplikasi, distribusi dan orkestrasi pada lapisan PaaS (Pahl, 2015), bahkan terhadap awan tepi dengan lingkungan sumber daya yang lebih kecil (Pahldan Lee, 2015).

• Dekomposisi fungsional suatu aplikasi dan tim adalah kunci utk membangun arsitektur layanan-mikro yang sukses. Ini mencapai kopling longgar (antarmuka REST) dan kohesi yang tinggi(beberapa layanan dapat saling menyusun untuk mendefinisikan layanan atau aplikasi tingkat yang lebih tinggi). Dekomposisi fungsional memungkinkan misalnya kelincahan, fleksibilitas, skalabilitas.

Tren penelitian

• Dalam hal kebutuhan yang dirasakan untuk penelitian, aspek berikutpenting mengenai metodologi dan dukungan (per-)alat(-an):

• • Pengujian sangat penting (micro services sebagai artefak desain menujumemenuhi kebutuhan integrasi)

• • teknologi semantik cerdas untuk manajemen mereka misalnya untukpenemuan di repositori.

• • Dihasilkan dari kemandirian, self-manageability diaktifkan oleh platformdeployment.

• Tren lebih lanjut dapat ditambahkan: migrasi micro services, autonomous healing, perubahan arsitektur runtime, pola arsitektur, DevOps dan layananmikro, pemantauan mikrolayanan, Auto-scaling dalam konteks micro services, optimasi konfigurasi untuk micro services, dan arsitekturrefactoring.

• Kesimpulan (sementara). Layanan Microservice hanya mendapat perhatian baru-baru ini (Lewis dan Fowler,

2014; Newman, 2015), didorong oleh dua factor sebagai berikut. Pertama, mereka mengatasi keterbatasan gaya SOA

(Erl, 2005), yang secara spesifik menghubungkannya dengan kemampuan penyebaran yang independen dan ringan.

Perusahaan seperti Netflix dan Thoughworks telah berada di garis depan dalam hal ini.

• Hal ini membawa pembahasan ini juga ke dalam konteks (kedua) pendekatan pembangunan yang

berkesinambungan (Fitzgerald dan Stol, 2014) seperti DevOps (Brunnert et al., 2015). Selanjutnya, teknologi Cloud

(Mell dan Grance, 2011; Antonopoulos dan Gillam, 2010) dan teknologi kontainer dalam konteks ini khususnya (Pahl

dan Lee, 2015; Pahl, 2015) menyediakan mekanisme untuk menyebarkan layanan mikro yang konsisten dengan

prinsip gaya. Pola microservice perlu dipetakan ke pola CLOUD (Pahl dan Jamshidi, 2015; Fehling et al., 2014).

• Service orientation adalah a key enabler untuk cloud-native application development. Microservices telah terbit sebagai state-of-the-art implementation approach untuk realisasi the Service-Oriented Architecture (SOA) style, mempromosikan modern software engineering and deployment practicesseperti containerization, continuous delivery, and DevOps. Mendesain antarmuka (micro-)services menjadi expressive, responsive, and evolvable adalah menantang.

• Misalnya, memutuskan untuk suited granularities adalah a complex task resolving many conflicting forces; one size does not fit all. Domain-Driven Design (DDD) dapat diaplikasi untuk mengidentifikasidan menspesifikasi service boundaries. Namun, service designers mencari concrete, actionable guidance going beyond high-level advice seperti “turn each bounded context into a microservice”. Interface signatures and message representations memerlukan particular attention seperti their structures influence the service quality characteristics.

• Direncanakan penelitian disertasi ini mengambil tipe riset philoshophical paper dan solution proposal. Dipertimbangkan mulai dari SaaS [1] hingga PaaS [2], dan CaaS serta Monitoring & Multi-cloud solution. Diketahui bahwa di hari-hari awal komputasi cloud hanya ada dua cara membangun platforms to deploy applications yaitu PaaS [2] dan IaaS+ [3]. PaaS [2] mungkin bukan solusi plug-and-play untuk aplikasidan layanan lawas yang ada. Sebagai gantinya, beberapa penyesuaian dan perubahan konfigurasimungkin diperlukan untuk sistem lawas agar dapat bekerja dengan layanan PaaS. Kustomisasi yang dihasilkan dapat menghasilkan sistem TI yang kompleks yang dapat membatasi nilai investasi PaaS sama sekali.

• CaaS adalah cara turn-key untuk menggunakan kontainer Docker, yang mengharuskan Anda untuk

mengembangkan aplikasi secara terpisah. PaaS vs CaaS: Manakah Pilihan yang Lebih Baik? Dengan

kata lain, PaaS dan CaaS tidak perlu cara yang berbeda untuk menyelesaikan masalah yang sama.

• Bagi perusahaan (institusi) yang mencari fleksibilitas tambahan yang tidak dipenuhi oleh

persembahan PaaS tradisional, kontainer sebagai layanan (CaaS) mungkin menjadi cara untuk

pergi (selesaikan masalah). CaaS dapat diimplementasikan di berbagai infrastruktur dan sistem operasi

dan dapat dimanfaatkan untuk seluruh gaya hidup aplikasi.

• Beberapa poin kunci penting yang memerlukan diskusi lebih lanjut. Ini termasuk: definisi layananmikro, ukuran dan batas mereka. Peneliti juga telah menjelajahi hubungan micro services denganSOA dan DDD. Ini adalah dua istilah yang sering dikaitkan dengan layanan mikro. Akhirnya, Penelititelah mendiskusikan DevOps, Cloud dan Virtualisasi sebagai tiga faktor yang paling pentingdalam ekosistem Layanan mikro. Peneliti berusaha untuk memperjelas peran masing-masing faktorini.

• Berdasarkan temuan Peneliti, masih belum ada definisi standar untuk layanan mikro to-date. Dalam ketiadaan pedoman yang jelas, SOA dan DDD konsep secara luas digunakan untukmengembangkan layanan mikro. Praktik DevOps bersama-sama dengan lingkungan awanmemainkan peranan penting dalam memfasilitasi pelaksanaan layanan mikro. Peneliti juga telahmengidentifikasi containerization sebagai metode yang efektif untuk mengatasi keterbatasanhardware selain mempercepat proses pengiriman. (Hamzehloui dkk, 2019).

• Tercantum di bawah ini adalah beberapa temuan mereka yang lain: hubungan yang erat antaraarsitektur mikro, DevOps, dan Cloud Containerization dan virtualisasi adalah teknologi yang memungkinkan efisiensi kinerja, Kemampu-rawatan dan keamanan adalah pada atas metrikkualitas pemantauan, manajemen tingkat sistem dan Service orchestration adalah tiga diskusiutama terkait infrastruktur.

PERMASALAHAN

• Daftar beberapa poin kunci dari kertas kerja: keamanan adalah topik yang tidak tercakup secaraekstensif. Praktik dan pola desain tidak dibahas dengan cukup. menemukan tingkat granularitasyang tepat untuk micro services masih menjadi masalah. HTTP & RESTful adalah metode komunikasiyang paling umum.

• Mereka berusaha untuk mencatat karakteristik layanan microservices. Kurangnya definisi standar untuklayanan mikro adalah masalah yang diketahui dalam komunitas perangkat lunak. Karenanya upayamereka dapat dipandang sebagai titik awal yang baik dalam membentuk definisi standar untuk layananmikro. Mereka mendaftarkan dua teknologi yang muncul yaitu: REST menduduki puncak daftar diikutioleh Swagger. Daftar teknologi paling umum yang saat ini digunakan. Docker berada di bagian atasdaftar ini dengan Node.js dan MySQL menjadi yang kedua dan ketiga.

• Area Debat. Karena layanan mikro adalah teknologi yang relatif baru, masih ada banyak perdebatanseputar mereka. Ini berkisar dari perspektif desain hingga kualitas dan kinerja metrik untuk pelaksanaandan pemeliharaan. FOKUS pada Definition of Microservices Architecture. Arsitektur microservices telah menjadi topik banyak penelitian, namun mereka tidak memiliki definisi yang tepat. Beberapa istilahyang paling sering digunakan untuk menggambarkan arsitektur mikrolayanan adalah:

• • Small in size • Single-responsibility • Loosely coupled • Explicitly published interfaces • Lightweight • Communicating via REST and HTTP

Tujuan Penelitian (secara khusus)

• Bagai mana melakukan systematic evaluation arsitektur RESTful dan WS-* yang hasilnya dapat mempermudah tugas mengoptimalkankomunikasi antar-services, yang mengeksekusi transaksi-transaksi di tengah eksistensi microservices architecture (framework & platform);

• Bagai mana hasil evaluasi arsitektur tersebut bisa bermanfaat dalammicroservices taxonomy (khususnya implementation → technologystack → data exchange→ REST /HTTP, RPC alike, dan MQ) gunamenentukan posisi dalam (Richardson) Maturity Model, termasuk Maturity Model untuk Semantic RESTful Web APIs.

Batasan permasalahan

Conceptual Architectural Framework of CloudComputing for Higher Educational Institutions

• Model layanan komputasi awan.

Fokus penelitian→metode pilihan

• Fokus penelitian disertasi ini diperkirakan adalah: 1) Q = user-facing, 2) E = architecture [RESTful dan WS-*], 3) P = migration, 4) T = Docker, 5) C = Data Center, 6) R = Analysis /comparison, 7) A = Learning Technology.

• Kita dapat mencatat secara khusus kurangnya teknologi terbukti untuk mewujudkan arsitekturlayanan mikro, pemahaman untuk membedakan SOA dari micro services, pemantauan alat untukmicro services, arsitektur pola untuk layanan mikro, pendekatan eksperimental untuk secaraempiris membandingkan micro services dengan gaya lain (misalnya menggunakan metodeevaluasi arsitektur seperti ATAM), alat untuk mengaktifkan kinerja-driven DevOps untukpengembangan arsitektur micro services, metode engineering perangkat lunak (metodologi, desainpola, praktik terbaik, jaminan kualitas, versi sistem, manajemen perubahan) untuk pengembanganarsitektur micro services, dan sukses /tidak berhasil contoh pengembangan micro services (hanyabeberapa ada, misanya CF Netflix).

• METODE EVALUASI ARSITEKTUR ➔ the Architecture Tradeoff Analysis Method, SM, (ATAM) →untuk menentukan apakah pengguna RESTful dan atau WS-* sebagai pengguna fasilitas internet atau penyedia fasilitas internet?

• Layanan web RESTful lebih dapat dipertahankan di sisi server, sementara layanan web SOAP-WSDL lebih dapat dikelola di sisi klien. Layanan web RESTful lebih dapat dikelola di sisi server dari pada layanan web SOAP-WSDL, yang lebih dapat dipelihara di sisi klien.

• Oleh karena itu, hasil saat ini menunjukkan bahwa perusahaan yang tertarik dalam menyediakan layanan web melalui internet dapatmengurangi biaya pemeliharaan terkait dengan menggunakanlayanan web RESTful. Sebaliknya, jika tujuan perusahaan adalahmenggunakan layanan web melalui internet, layanan web SOAP-WSDL menawarkan biaya perawatan yang lebih rendah.

Workflow dalam Microservices Land

• Metode penelitian untuk layanan mikro. Biasanya, jenis kontribusi(Proposal Solusi, Penelitian Evaluasi, Penelitian Validasi, LaporanPengalaman, Tinjauan) dan metode evaluasi (Studi Kasus, Bukti Matematika, Laporan Pengalaman, Contoh Aplikasi, EksperimenTerkendali) dibedakan. Studi utama diselenggarakan sesuai denganjenis kontribusi mereka.

• Mengingat ketidakmatangan relatif dari domain, evaluasi tersebuttidak memiliki laporan pengalaman dan bukti yang terperinci, sementara eksperimen yang dikontrol sama, implementasi sampelsebagai laporan pengalaman dan beberapa eksperimen terkontroltelah dilaporkan.

• Gambar terkait melengkapi ini dengan melihat kontribusi teknis lebihspesifik (mengkategorikan studi non-solusi seperti laporanpengalaman, evaluasi dan ulasan sebagai 'lain-lain'). Info menarikadalah pemisahan ≈ 3:2 antara perspektif arsitektur dan perspektifmetode.

• Systematic evaluations and experience reports on the one hand (Eval [Evaluation], Exp [Experience report]) and technology reviews (Rev) are equally frequent. Melihat kondisipeneliti, kemungkinan penelitiandisertasi ini akan diarahkan ke Eval(prioritas) atau Exp dengan pilihankonteks yaitu AI [Artificial Intelligence] atau MD [MethoD].

• Gambar 2.66. Distribusi studi oleh kontribusi teknikalmelalui tipe kontribusi (bubble plot). Horizontal: Sol: solution, Val: validation, Eval: evaluation, Exp: experience report, Rev: review. Vertikal: “AI”: Architecture Implementation, AM: Architecture Method, AV: Architecture Validation, MD: Method Definition, MV: Method Validation, Oth: Others.

Evaluasi Metode Konstruksi Layanan Mikro

• Comparative analysis with related research.

• Perlu dipikirkan aplikasi-aplikasi yang memanfaatkan cloud infrastructure sesuai urutan prioritaspentingnya seperti: 1) CRM [Customer Relationship Management], 2) ERP [Enterprise Resource Planning], 3) O&M [Operation & Manufacturing /Maintenance /Management], 4) SCM [Supply Chain Management], 5) CMS [Content Management Systems], 6) Collaborative /Security /Engineering –Solution, 7) SDM [Structure Data Management], 8) System /Network – Management, 9) Storage Software, 10) Application Server Middleware, 11) Integration & Process Automation Middleware, 12) Quality & Lifecycle Tools.

• REST(ful) dan Web Services (WS-*)

• Ada dua gaya arsitektur bersaing yang digunakan untuk membangunlayanan Web: layanan RESTful dan layanan berdasarkan standar WS-* (juga diketahui sebagai SOAP). Kedua gaya ini memiliki basis pengikutyang terpisah, tetapi banyak perbedaan di antara mereka adalahideologis dari pada faktual.

• Urutan pertama penelitian adalah untuk mengidentifikasi prinsip-prinsip yang baik untuk membuatperbandingan. Zarras mengidentifikasi prinsip-prinsip berikut untuk membandingkan infrastrukturmiddleware: keterbukaan, skalabilitas, kinerja, transparansi distribusi. Properti arsitektur perangkat lunakadalah sumber prinsip lain untuk dipertimbangkan. Kemungkinan lain adalah menerapkan kembalipendekatan berprinsip, yang digunakan oleh Fielding untuk mendapatkan REST, untuk menentukan gayaarsitektur RESTful dan WS-*. Ini akan memerlukan penerapan batasan tambahan, satu per satu, untukmendapatkan definisi lengkap dari gaya arsitektur.

• Sampai beberapa tahun yang lalu, ada dikotomi sederhana antara REST dan WS-*. Layanan RESTful hanya digunakan untuk layanan publik yang sederhana. Sebaliknya, standar perusahaan, vendor alat, dan komunitaspenelitian hanya khawatir dengan layanan WS-*.

• SEKARANG, hal ini tidak lagi terjadi - kedua gaya sedang digunakan di semua domain. Tantangan baru adalah menggunakannya dengan benar, dan untuk dapat menyelaraskannya untuk menyelesaikan masalah nyataperusahaan /institusi.

• Kami mempertimbangkan dua gaya dominan layanan Web: RESTful dan WS-*. Istilah Representational State

Transfer (REST) adalah diciptakan oleh Roy Fielding untuk mengidentifikasi gaya arsitektur berdasarkan seperangkat

prinsip untuk merancang arsitektur perangkat lunak berbasis jaringan [12].

• Selanjutnya, istilah ini diperluas untuk menggambarkan gaya membangun layanan Web berdasarkan prinsip-

prinsip REST. Kami menggunakan istilah RESTful untuk merujuk pada layanan Web yang dibangun sesuai dengan

gaya arsitektur (atau bagian dari itu).

• Kami menggunakan istilah WS-* untuk merujuk ke layanan berdasarkan standar SOAP dan standar WS-* lainnya

(misalnya WS-Addressing, WS-Security), yang didefinisikan khusus untuk layanan Web.

REST PRINCIPLES

• Principles. Roy Fielding mendokumentasikan REST berdasarkan prinsip-prinsip yang muncul sebagai Web

berevolusi [12]. Dia memperhatikan bahwa server Web, klien, dan perantara berbagi beberapa yang memberi mereka

ekstensibilitas untuk bekerja pada skala besar Internet. Dia mengidentifikasi empat prinsip REST (yang disebutnya

kendala) [12]:

• 1. Identifikasi sumber daya (Identification of resources),

• 2. Manipulasi sumber daya melalui representasi (Manipulation of resources through representations),

• 3. Pesan deskriptif sendiri (Self-descriptive messages),

• 4. Hypermedia sebagai mesin status aplikasi (disingkat HATEOAS, Hypermedia as the engine of application state ).

• Identification of Resources. Setiap perancang layanan RESTful harusmenjawab pertanyaan: Apa yang merupakan sumber daya sistem? Idealnya, konsep apa pun dalam sistem yang memiliki representasi harusdiekspos sebagai sumber daya. API RESTful harus memetakan layanan kesumber daya, bukan untuk implementasi internal layanan. Tetapi banyaklayanan yang ada melakukan ini salah.

• Representations. Jika sumber daya mendukung beberapa representasi, sumber daya dapat menghasilkan respons dalam format data yang berbeda. Dalam HTTP, klien menentukan format pilihan mereka di Accept-* header untuk negosiasi konten. Dengan mengonfirmasi ke HTTP, layananWeb RESTful dapat mendukung beberapa jenis format respons (MIME), seperti yang dilakukan Web, yang membuatnya mudah untuk mematuhiprinsip ini.

• Self-descriptive Messages. REST membatasi pesan yang disosiasikanoleh komponen agar memiliki deskriptif sendiri (yaitu definisi standar) untuk mendukung pemrosesan interaksi oleh perantara (Proksi, gateway). Meskipun HTTP / 1.1 mendefinisikan 8 metode, hanya duadari mereka, GET dan POST, telah digunakan secara luas di Web, sebagian karena satu-satunya metode yang didukung oleh browser Web.

• HATEOAS. Hypermedia as the engine of application state berarti bahwa klien maupun server tidakperlu menjaga status pertukaran dalam sesi, karena semua informasi yang diperlukan disimpandalam pesan HTTP yang dipertukarkan (di URI dan header HTTP yang menyertainya). Mendefinisikan tautan mandiri sangat penting untuk RESTful Web layanan, karena tautan inimemungkinkan untuk melintasi, menemukan, dan layanan dan aplikasi lainnya.

SYSTEMATIC EVALUATION

• Bagian pertama adalah usaha mengatasi kekurangan micro services yang menyulitkan pada tugas-tugas: 4) mengoptimalkan komunikasiantara services, dan 3) mengeksekusi transaksi-transaksi.

• Usaha itu antara lain: Karena masih sedikit penelitian yang menyelidiki bagaimana microservices digunakan dalam prakteknya, dilakukan studi pemetaan, yang merangkum kemajuan teknologimicro services terkait dua tugas tersebut (3 & 4).

• Studi pemetaan untuk mengidentifikasi dan menyoroti potensikeuntungan dan tantangan yang dihadapi oleh para profesional yang bekerja dengan microservices terkait dua gaya itu (RESTful & WS-*).

• Disurvei tentang temuan studi pemetaan, yang bertujuan untukmemverifikasi apakah penggunaan microservices di industri ini sesuaidengan rekomendasi terbaik yang disebutkan dalam literatur dan apakah keuntungan dan tantangan yang ditemukan dalam studipemetaan pada kenyataannya apa yang dihadapi praktisi.

• Bagian kedua, dalam rangka mengakomodasi variabilitas, diusulkansebuah kerangka kerja untuk perangkat lunak berbasis microservices berdasarkan pendekatan Software Product Line Engineering (SPLE).

• Framework ABS (Abstract Behavioral Specification) Microservices Framework, karena mengandalkan platform pengembangan Software Product Line Engineering (ABS) yang siap mendukung SPLE.

Proses SPLE dalambingkai kerja layanan mikro ABS

• Penelitian disertasi masih berkutat di domain engineering pada problem space. Rencananya proses berlanjut ke bawah (application engineering) untuk menyediakan himpunan fitur. Dikarenakan durasiwaktu yang terbatas, belum sempat dikerjakan sisi kanan yaitu: solution space menuju penyediaan common implementation artifacts. Jadi pada problem space, penelitian masih berkutat focus pada urusan variability dengan problem area, sedikit dibahasstructure and selection rules untuk elemen-elemen solusi Product Line platform. Juga focus pada specification product variant, sedikitdibahas elemen-elemen platform yang dibutuhkan (dan elemen-elemen aplikasi tambahan jika diperlukan). Fokus pada RESTful & WS.

• Kesimpulannya, dari studi pemetaan, Layanan mikromuncul sebagai gaya arsitektural (RESTful & WS-*), tetapi salah satu yang meluas dari 'desain-tahaparsitektur' ke dalam penyebaran dan operasi sebagaigaya pengembangan terus menerus – dimensi'metode'. Hal ini juga tampak dari bagian penting daristudi ditinjau untuk menjadi intrinsicly terkait dengankontainer berbasis awan untuk penyebaran dan manajemen dinamis – dimensi 'arsitektur dinamis'.

• Perbandingan di antara REST dan WS-* Principles. Dijelaskan duaupaya untuk membandingkan layanan REST dan WS-* pada tingkatabstrak. Pautasso dkk. Dalam perbandingan paling komprehensifhingga saat ini, Pautasso et. al. [34] membandingkan layanan RESTful dan WS-* pada tiga tingkat: 1) prinsip arsitektur, 2) keputusankonseptual, dan 3) keputusan teknologi [1 3: biasa rinci].

• Empat properti sistem layanan RESTful adalah: 1) antarmuka seragam, 2) addressability, 3) statelessness, dan 4) keterhubungan. Dalamlayanan Web RESTful, properti ini diwujudkan dalam sumber daya, URI, representasi, dan tautan di antara mereka.

• Sebaliknya, layanan WS-* menunjukkan tiga dari empat properti ini. Addressability dan beberapa bentuk keterhubungan tertanam dalamdefinisi WSDL dari binding dan port. Banyak layanan WS-* stateless (meskipun bukan persyaratan eksplisit). Memiliki antarmuka seragam yang dibagikan oleh semua layanan adalah satu-satunya properti tidak didukungoleh WS-*. Karena beberapa properti ini relevan dengan keduanya, properti tersebut adalah pilihan yang baik untuk perbandingan.

• Survey of Existing Web Services. Salah satu hambatan untuk mempelajarilayanan Web yang ada adalah fakta bahwa banyak dari mereka tidak dapatdiakses oleh dunia luar, karena mereka adalah hak milik. Sistemkepemilikan memiliki persyaratan yang berbeda (lebih sedikit ancamankeamanan karena kerentanan yang terkenal, tidak perlu mematuhi standarumum) yang menghasilkan berbagai pilihan teknologi layanan Web.

• Open Research Problems of RESTful Services. REST berasal daripersimpangan akademisi dan pengembangan perangkat lunak, di antara arsitek World Wide Web. Penelitian Fielding memuncak dalamversi otoritatif standar HTTP dan URI yang menentukan karakteristikunik Web. Sayangnya, para peneliti baru-baru ini mulai bekerja pada layanan RESTful. Pada akhir 2007, tidak ada makalah tentang layananWeb RESTful di Konferensi ICWS, ECOWS, atau WWW. Pada tahun2010, ICWS telah menampilkan beberapa makalah tentang layananRESTful dan konferensi WWW telah menyelenggarakan "Workshop on RESTful Design (WS-REST 2010) pertama" [33], yang merupakantanda selamat datang.

• Caching. Dari banyak aspek kinerja, caching adalah salah satu contohterbaik mengapa ia membayar untuk menggunakan HTTP denganbenar. Data dapat di-cache oleh klien, oleh server, atau oleh perantara, seperti proksi Web.

• Maintainability. Tugas pemeliharaan umum layanan Web (menambahkan fitur baru, memperbaiki layanan API) mempengaruhilayanan itu sendiri, dokumentasi mereka, kode klien, dan bahkan alatpengembangan.

• Security and Privacy. Mengamankan layanan Web RESTful adalah upayamulti-faceted: melibatkan pengamanan data, serta seluruh komunikasi. Seseorang harus melindungi kerahasiaan dan integritas data. Data saattransit harus difilter untuk muatan berbahaya. Komunikasi harusmendukung otentikasi dan kontrol akses, dan memastikan bahwa privasipihak yang berkomunikasi tidak terganggu.

• QoS. Ketika beberapa penyedia menawarkan layanan yang sama, klienmemiliki pilihan dan dapat memilih yang paling cocok. Seringkali, pilihan inibermuara pada parameter Quality of Service (QoS). Layanan Web RESTful hari ini mengabaikan persyaratan QoS; satu-satunya kekhawatiran merekaadalah menyediakan antarmuka fungsional.

• Studies of Existing Systems. Layanan web adalah kandidat yang baik untukmempelajari konsep rekayasa perangkat lunak dari sistem besar yang tersedia untuk umum. Tetapi ada beberapa studi yang berhasil tentanglayanan RESTful, atau perbandingan berdampingan dari layanan yang memaparkan dua antarmuka yang didefinisikan dalam gaya bersaing (satuRESTful, satu WS-*). Tidak mudah untuk membandingkan kedua gaya inipada tingkat prinsip.

• Conclusion. Layanan Web RESTful (dan layanan Web secara umum) menimbulkan ujian besar pertama dari prinsip-prinsip REST, seperti yang diidentifikasi oleh Fielding. Meskipun layanan RESTful mungkin terlihatseperti sistem Web biasa, mereka tidak, layanan WS-* jelas berbeda.

Richardson Maturity Model

• Bermula dari heterogenitas mengenai adopsi prinsip REST. Beberapa sangatdiadopsi (tetapi juga mudah disesuaikan, seperti Client-Server) sementara yang lain hampir tidak diadopsi (misalnya, Antarmuka Seragam) → Richardson Maturity Model merupakan cara memahami kepatuhan (terhadap) prinsip-prinsip REST. Richardson used three factors to decide the maturity of a service i.e. URI, HTTP Methods and HATEOAS (Hypermedia).

• A Maturity Model for Semantic RESTful Web APIs: API Web menyediakanantarmuka untuk interaksi di antara sistem berdasarkan infrastruktur yang adauntuk meng-hosting situs web dan aplikasi. Gaya arsitektur REST adalahpendekatan yang paling banyak digunakan untuk membangun API Web. Namun, fleksibilitas yang diberikan oleh REST dapat mengakibatkan implementasi dengandesain berkualitas rendah, penggunaan kembali terbatas, dan dokumentasi yang buruk→maturity model untuk mengklasifikasikan API Web, yang bertujuanuntuk mempromosikan kepatuhan terhadap prinsip arsitektur REST dan adopsiteknologi Web semantik untuk meningkatkan desain, penggunaan kembali, dan dokumentasi API Web.

Milestones

• Karena tanpa sarana standar utk mendokumentasikan API, kecenderungannya adalah menggunakan teks utk menggambarkanAPI (berkali-kali dalam natural language), yg mungkin beragam dlmform, structure, or depth dan jelas merupakan masalah bagipengembang client. Bagai mana usaha standarisasi? Documentationcan be manually created or generated by software. There are several API development tools on the market, which help not only designing and testing an API, but also documenting it.

• Memahami bagaimana alat pengembangan layanan REST (misalnya, Swagger tool set) mempengaruhi kepatuhan terhadap prinsip-prinsipatau praktek (dan tingkat adopsi pengembang yang sebenarnyamengenai SDK yang disediakan).

• Comparative evaluation of the maintainability of RESTful and SOAP-WSDL web services

https://www.researchgate.net/publication/261039282_Comparative_evaluation_of_the_maintainability_of_RESTful_and_SOAP-WSDL_web_services

https://www.academia.edu/16293971/Comparative_evaluation_of_the_maintainability_of_RESTful_and_SOAP_WSDL_web_services

• Comparison of SOAP and REST Based Web Services Using Software Evaluation Metrics https://www.researchgate.net/publication/312566917_Comparison_of_SOAP_and_REST_Based_Web_Services_Using_Software_Evaluation_Metrics

• Review, Composition of heterogeneous web services: A systematic review https://www.sciencedirect.com/science/article/abs/pii/S108480451930205X

• Load Index Metrics for an Optimized Management of Web Services: A Systematic Evaluation https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0068819

• REST API vs SOAP rest api vs soap – YouTube

• When to Use REST vs. SOAP with Examples When to Use REST vs. SOAP with Examples - API Blog: Everything You Need to Know (dreamfactory.com)