UTS KomLay (IF4052 Komputasi Layanan)
Bahan belajar UTS yang disusun dari catatan 1, 2, 4, 5, 10, dan 17. Ini studi sheet, bukan pengganti catatan asli: tiap bagian me-link ke note sumber untuk detail dan flashcard aslinya. Istilah singkat ada di Glosarium_KomLay.
Cara pakai: baca Prasyarat dulu, lalu Materi inti dari atas ke bawah. Urutannya disusun menurut ketergantungan konsep, jadi sebuah konsep selalu dijelaskan sebelum dipakai. Konsep yang sudah dijelaskan tidak diulang, hanya dirujuk (“lihat 2.x”).
0. Cakupan dan Peta CPMK
Cakupan: materi di zip OneDrive_1_10-8-2026.zip yang kamu sebut untuk UTS. Isinya tujuh PDF: W01b (Pengantar Komputasi Layanan), W02a (A Closer Look at SOA), W02b (SOA dan Web Service), W04 (Microservices), W05a (Poster SOA Design Principles), W06a (Myth of SOA), dan Cloud Computing. Peta ke note: 1 (W01b), 2 (W02a dan W02b), 4 (W04), 5 (W05a), 17 (W06a, note baru), 10 (Cloud Computing). W03 (BPM dan BPMN) dan W05b serta materi lain (design patterns, SoaML, integration, GraphQL, WSLA, testing, security) tidak ada di zip, jadi tidak dibahas di sini. Catatan: W01b, W02a, W02b, dan Cloud Computing di zip berbeda isinya dari berkas lama di _Materi/KomLay/ppt/; perbedaannya sudah dimasukkan ke note 1, 2, dan 10. W04 dan W05a identik dengan berkas lama.
| Luaran (CPMK) | Bagian di file ini | Status |
|---|---|---|
| 1. Memahami service dan arsitektur service, standar untuk service, siklus hidup service, dan pembangunan perangkat lunak berorientasi service | 2.1 sampai 2.8 (service, SOA, web service, composition, lifecycle), 2.11 (mitos) | Tercakup |
| 2. Mampu menggunakan kakas dan platform untuk pembangunan perangkat lunak berorientasi service | 2.6 (WSDL, SOAP, UDDI, BPEL), 2.9 (microservices), 2.10 (cloud: SaaS/PaaS/IaaS) | Tercakup sebagian (konsep kakas, praktik ada di tugas) |
| 3. Mampu mempraktekkan pembangunan perangkat lunak berorientasi service | 2.8 (analysis dan design), 2.9 | Tercakup sebagian (praktik ada di tugas) |
1. Prasyarat: Istilah yang Harus Dipahami Dulu
Istilah di bagian ini dipakai di materi tanpa penjelasan. Dicek dengan pencarian teks di note KomLay 1-17 (slide PDF mentah tidak dicari). Penjelasannya adalah tambahan di luar materi kuliah. Istilah seperti ESB, middleware, dan EAI muncul juga di 8_SOA Integration dan 9_Integration Patterns (di luar cakupan UTS ini), jadi lihat sana untuk penjelasan lengkap.
| Istilah | Penjelasan (tambahan) |
|---|---|
| RPC (Remote Procedure Call) | Cara memanggil fungsi yang berjalan di komputer lain seolah fungsi lokal. Service “bukan cara baru melakukan RPC”. |
| Legacy system | Sistem lama yang masih dipakai dan penting bagi bisnis, biasanya dibangun dengan teknologi lama sehingga sulit disambungkan ke sistem baru. |
| CRM | Customer Relationship Management: sistem untuk mengelola data dan interaksi dengan pelanggan. |
| ROI (return on investment) | Perbandingan keuntungan terhadap biaya yang dikeluarkan. |
| Ontologi | Penjelasan formal tentang istilah dan hubungan antar istilah dalam satu bidang, supaya pihak berbeda memakai arti yang sama. |
| Continuous Integration / Continuous Delivery (CI/CD) | Praktik menggabungkan perubahan kode sering-sering dan merilisnya secara otomatis dan berkala. |
| Container dan virtual machine | Cara membungkus aplikasi agar berjalan terisolasi. Virtual machine meniru satu komputer lengkap beserta OS-nya; container lebih ringan karena berbagi OS inti. |
| Bounded context | Batas tempat sebuah istilah dan model data punya satu arti yang konsisten (dari domain-driven design); dipakai untuk menentukan batas microservice. |
| Commodity computer dan datacenter | Komputer biasa berharga murah (bukan mesin khusus mahal), dikumpulkan dalam jumlah sangat besar di gedung datacenter. |
| Statistical multiplexing | Berbagi satu kapasitas oleh banyak pengguna dengan asumsi mereka tidak semuanya memakai kapasitas penuh bersamaan, sehingga utilisasi naik. |
| HIPAA, Sarbanes-Oxley | Regulasi AS tentang kerahasiaan data kesehatan (HIPAA) dan pelaporan keuangan perusahaan (Sarbanes-Oxley). |
| Single point of failure | Satu komponen yang bila gagal membuat seluruh sistem berhenti. |
2. Materi Inti (Urut Menurut Ketergantungan Konsep)
2.1 Service dan Service Computing
Sumber: 1_Pengantar Service Computing
Definisi layanan (service):
- KBBI (jasa): perbuatan yang baik atau berguna bagi orang lain, perbuatan yang memberikan segala sesuatu yang diperlukan orang lain, aktivitas atau manfaat yang dapat dijual ke konsumen.
- Merriam-Webster: pekerjaan yang dilakukan oleh yang melayani; bantuan, kegunaan, manfaat.
- Oxford: aksi membantu atau melakukan pekerjaan untuk seseorang; sistem yang memenuhi kebutuhan publik (transportasi, komunikasi, listrik, air). Secara ekonomi, padanan non-material dari suatu barang: service tidak menghasilkan kepemilikan (beda dari barang fisik). Dalam produksi, proses yang menghasilkan manfaat dengan memfasilitasi perubahan pada pelanggan, kepemilikan fisiknya, atau aset tak berwujudnya.
Ilustrasi dunia nyata ke computing: cuci kiloan (anak kost tanpa mesin cuci), sarapan kupat tahu (tidak sempat masak), taksi lalu aplikasi ride-hailing, lalu di computing: layanan NTP untuk sinkronisasi jam, dan web service currency converter untuk e-commerce.
Dalam konteks computing: pengembang tidak perlu membangun semua fungsionalitas sendiri; fungsionalitas disediakan oleh service provider (“server”); pengguna disebut service requester (“client”); sebuah service dapat memakai service lain (seperti tukang kupat tahu memakai jasa delivery).
Service computing (Bouguettaya dkk., A Service Computing Manifesto: The Next 10 Years, CACM April 2017): disiplin yang mengembangkan abstraksi komputasional, arsitektur, teknik, dan tools untuk mendukung service secara luas. Service orientation: paradigma yang mengubah aset fisik, hardware, dan software sehingga pengguna dan aset menjalin interaksi on-demand, mengikat resource dan operasi, dengan lapisan abstraksi yang menggeser fokus dari infrastruktur dan operasi ke service.
Service BUKAN: teknologi spesifik, jawaban akhir untuk reuse, nama baru untuk EAI (Enterprise Application Integration), atau cara baru melakukan RPC.
2.2 SOA: Definisi, Visi, dan Elemen
Sumber: 1_Pengantar Service Computing (memakai 2.1)
SOA adalah gaya arsitektur pengembangan perangkat lunak:
- Semua komponen IT (basis data, server, sistem CRM, dll.) diperlakukan sebagai building block siap pakai (plug and play).
- Fokus pada pengembangan dan pemanfaatan (use and reuse) program kecil bernama service.
- Service dipandang sebagai komponen pembangun perangkat lunak dan dibangun untuk dipakai beberapa aplikasi, bukan satu.
- Definisi arsitektur (IEEE Standard 1471): “the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.”
- Keuntungan bagi organisasi: lean, agile, flexible (memanfaatkan sumber daya yang ada) dan mudah beradaptasi terhadap perubahan pasar dan teknologi.
Analogi restoran Italia:
| Elemen restoran | Konsep SOA |
|---|---|
| Restoran menyediakan makanan | a service |
| Setelah order, makanan dibuat, disajikan, dst | service dapat terdiri dari service lain |
| Menu menunjukkan layanan yang tersedia | service description |
| Order ditulis atau diteriakkan ke koki | service berkomunikasi lewat messages |
The SOA vision: lingkungan intra-/inter-organisasi di mana service apa pun dapat memanggil service lain (mungkin remote). Tipe service: business service, data service, infrastructure service. Service = Contract + Terms + QoS:
- Contract: apa yang dilakukan service (opsional dideskripsikan).
- Terms: properti pada service, mis. atomicity, isolation, proteksi keamanan, apa yang terjadi bila service gagal.
- Quality-of-Service (QoS): kondisi pengiriman layanan, terkait performance, reliability, dsb (mis. pesan harus sampai dalam 5 detik, downtime setahun maksimal 5%).
- Service dapat dipandang sebagai generalized procedure.
Ilustrasi bank: tiga kanal klien (Tellers, ATM, Web) memakai service yang sama (Withdrawal, Deposit, Balance Check, Loan Payment, Rate Calculation); Transfer dikomposisi dari Withdrawal dan Deposit. Poin: satu service dipakai ulang oleh banyak kanal. Sumber: Newcomer dan Lomow, Understanding SOA with Web Services.
The SOA triangle: tiga entitas: Service Provider (publish deskripsi service ke discovery agency), Discovery Agencies (menyimpan service description), Service Requestor (find service lewat discovery agency). Setelah ketemu, requestor dan provider interact langsung.
Main ingredients: (1) Services, (2) Service descriptions, (3) Messages, (4) Policy. Implementasi umumnya lewat web services.
SOA sebagai sistem OO “sungguhan”: service requester mengirim message ke service provider (↔ message passing); service description ↔ protocol/interface/daftar method kelas; requester tidak tahu representasi internal provider (↔ enkapsulasi). SOA berhasil mencapai “holy grail” OOP yang gagal diwujudkan OO murni: objek yang dibuat dengan bahasa dan platform berbeda bisa saling berkomunikasi.
2.3 Dari Sistem Terisolasi ke SOA, Integrasi, dan Interoperabilitas
Sumber: 2_SOA dan Web Service (memakai 2.2)
Evolusi: (1) the old days (non-networked): hubungan antar sistem dalam satu organisasi hanya lewat sneaker-net (membawa disket) atau batch feed, antar organisasi lewat telepon atau surat; (2) the new days (distributed networked): sistem internal terhubung lewat jaringan, aplikasi berinteraksi dengan sistem berbeda lewat jaringan atau Internet tetapi belum standar (dan tidak semua organisasi menyediakan konektivitas bagi aplikasi); (3) the newer days (SOA-based): ada SOA Infrastructure di tengah yang menyediakan service dengan interface standar, aplikasi baru mudah dibuat dari fungsionalitas yang ada, dan organisasi eksternal bisa mengakses fungsionalitas internal lewat interface standar.
Service sebagai komponen yang dapat dipakai ulang: customer lookup, account lookup, credit card validation, credit check, hotel reservation, interest calculation; bisa didistribusikan global antar organisasi dan dikonfigurasi ulang menjadi proses bisnis baru. Slide W02a berdasarkan tutorial Grace Lewis dkk. (ICSM’06).
Masalah “islands of automation”: tiap departemen (Purchasing, Sales, Financial, Manufacturing, HR) punya sistem terisolasi dengan data yang mengalir hanya ke pengguna sistem masing-masing, tanpa integrasi lintas sistem.
The age of integration: survei CIO Magazine (Februari 2002): Integrated Systems and Processes 36%, Implementing New Technologies 26%, Staff Retention, Hiring, Training 25%, External CRM 24%, Lowering Costs 22%, Enabling E-Commerce 21%, dst; 33% perusahaan punya proyek EAI (Forrester, Maret 2002). Business integration imperative: integrasi lintas aplikasi enterprise dan database membuka peluang menyajikan satu wajah terpadu ke customer dan proses end-to-end yang efisien. Pre-SOA vs Post-SOA: pre-SOA integrasi dilakukan di luar dan sesudah pengembangan; post-SOA integrasi ada di dalam, bagian integral dari model pengembangan. Sejarah integrasi: 1950-1970an manual; 1970-1980an distributed computing; 1990an business-driven (workflow, business process, Web; muncul ETL, EAI, BPM); 2000 SOA dan Web services; 2003 evolusi dipercepat dan terjadi kekacauan vendor; 2006-2012 integrasi menjadi model pemrograman dominan.
Interoperability adalah kemampuan dua atau lebih aplikasi berbagi data dan layanan. Dua jenis: syntactic (aplikasi memakai format data dan proses yang sama) dan semantic (data dan proses benar-benar punya makna yang sama; lebih sulit). Interoperability woes: bisnis hanya mengotomatiskan sebagian kecil proses transaksi (pemesanan cepat tetapi akuntansi, inventori, pembayaran tertinggal), sehingga risiko kredit meningkat dan butuh rekonsiliasi mahal; bisnis hari ini harus berbasis protokol bersama yang menjamin interoperabilitas.
Requirements untuk eBusiness: permintaan harus terpenuhi hampir real-time; semua sistem bisa berkomunikasi ke segala arah dengan sistem mana pun; semua informasi relevan bisa diakses sistem lain; data dan proses bisnis harus sharable antar aplikasi terhubung, baik dalam maupun antar perusahaan, untuk menjamin data and process integrity.
2.4 Operasi Dasar Service, Registry, Invocation, dan Manfaat SOA
Sumber: 2_SOA dan Web Service (memakai 2.2 dan 2.3)
| Operasi | Deskripsi | Tantangan utama |
|---|---|---|
| Service Discovery | Service repository di-query untuk service dengan karakteristik diinginkan | Deskripsi service dan pemeliharaan repository |
| Service Composition | Service diintegrasikan ke aplikasi | Konversi I/O dan manajemen transaksi |
| Service Invocation | Service dipanggil dan kodenya dieksekusi | Ketersediaan (availability) service |
Static vs dynamic: static (teknologi saat ini): discovery dan composition saat design time (developer mencari service, mendapat alamat, menulis kode pemanggil). Dynamic (riset lanjut): saat runtime (aplikasi menemukan, mendapat alamat, dan “tahu” informasi yang harus diberikan). Ada pendekatan in-between: aplikasi menemukan service tetapi butuh intervensi pengguna untuk memilih dan memberi informasi (mis. portlets yang berkorespondensi dengan service).
Service registry berisi: deskripsi, spesifikasi (kontrak), klasifikasi, riwayat penggunaan, hasil test, metrik performa, dokumentasi. Registry juga bisa melacak service consumer: memahami service level yang dibutuhkan, memfasilitasi analisis dampak perubahan, dan notifikasi perubahan service.
Service invocation, tiga cara: (1) direct invocation (request lalu response); (2) via discovery (service query ke Discovery untuk mendapat service location, baru request/response); (3) via broker (aplikasi bertanya ke Service Broker yang meng-query satu atau banyak Discovery; lebih fleksibel, mis. load balancing).
Di balik interface: service consumer berinteraksi lewat service interface (abstraksi); implementasinya bisa new service (dibangun baru), wrapped service (membungkus aplikasi non-SOA yang ada), atau composite service (gabungan beberapa service). Endpoint terdiri dari Address (where, lokasi), Binding (how, protokol komunikasi), dan Contract (what, apa yang bisa dilakukan); client mengirim message ke endpoint.
Manfaat SOA (jika dikelola dengan baik):
- Cost-efficiency: satu service dengan fungsionalitas setara dipakai banyak aplikasi (mis. Customer Lookup Service dipakai Order Processing, Invoicing, dan CRM sekaligus).
- Agility: aplikasi baru mudah memakai service yang tersedia (mis. Course Management Application memakai Customer Lookup, Credit Check, Room Availability); service baru bisa dipakai aplikasi lain.
- Adaptability: perubahan pada service (mis. Credit Check) cenderung tidak berdampak pada aplikasi yang memakainya karena SOA Infrastructure menyediakan komunikasi standar.
- Leverage of legacy systems: service meng-invoke sistem legacy, sehingga keragaman platform legacy transparan bagi aplikasi (tugas service-lah memanggil legacy).
- “The hard part is the ‘if managed well’”: SOA bukan jaminan sukses; governance menentukan.
Contoh composition (W02a): Order Processing Application membuat formulir order cetak: Customer ID dipakai memanggil Customer Pending Orders (pesanan tertunda), Customer Financial Status (saldo), dan Customer Lookup (informasi customer). Komponen sistem berbasis SOA: aplikasi (X, Y, Z) ke SOA Infrastructure (Security, Development Tools, Discovery, Service Registry), lalu service yang membungkus Enterprise Information System, kode legacy atau baru, atau sistem eksternal lewat Internet.
2.5 Model Service (Taksonomi)
Sumber: 2_SOA dan Web Service (memakai 2.4)
Taksonomi pertama:
| Tipe | Konteks | Deskripsi |
|---|---|---|
| Task Service | Non-agnostic | Business logic single-purpose; mengenkapsulasi composition logic untuk menggabungkan service lain |
| Entity Service | Reusable, agnostic | Terkait satu atau lebih entitas bisnis (invoice, customer, claim), mis. Purchase Order service |
| Utility Service | Agnostic | Tidak diturunkan dari analisis bisnis; fungsi teknis level rendah (notifikasi, logging, security) |
Taksonomi kedua:
| Level | Karakteristik |
|---|---|
| Business | Abstrak, terkait bisnis; uji litmus “Are we in the business of…?” (mis. Creating Orders) |
| Enterprise | 1:N terhadap Business Service; granularitas tidak ditentukan, sering coarse-grained, bisa berbasis produk |
| Application | Fine-grained, terikat aplikasi spesifik |
| Infrastructure | Auditing, Logging, Security |
Alur: business services ↔ message bus (berisi process choreographer dan service orchestrator) ↔ enterprise services → application services → infrastructure services.
Shared resource dan contract decoupling: SOA memungkinkan shared resource (mis. beberapa divisi asuransi yang masing-masing punya data customer disatukan lewat satu customer service). Contract decoupling dengan ESB/Integration Hub: format data diterjemahkan (mis. XML SKU+tanggal ke Java product-id+quantity) lewat lapisan transformation and enhancement, sehingga business service dan enterprise service tidak perlu berbagi format data mentah.
2.6 Web Service dan Standar Terbuka
Sumber: 2_SOA dan Web Service (memakai 2.2 sampai 2.5)
Web service: layanan yang diekspos dan diakses lewat teknologi web. W3C: “a software system designed to support interoperable machine-to-machine interaction over a network.” Diimplementasikan dengan standar dan protokol untuk mendefinisikan service di web (OASIS, W3C); menghilangkan kebutuhan middleware khusus.
Standar terbuka: XML, SOAP, WSDL, UDDI, REST; untuk memodelkan proses: BPEL (Business Process Execution Language) dan BPMN (Business Process Model Notation). Web service stack (W02b, versi 2022/2023): dari bawah, network (HTTP, FTP, …), messages (SOAP), description dan discovery (WSDL, UDDI), composition (BPEL4WS); REST di slide itu masih ditandai tanda tanya.
- XML: vocabulary didefinisikan dalam schema (collection of trees); hanya mendefinisikan sintaks, bukan semantik. Semantic Web dan Web 2.0 menambah semantik lewat OWL dan turunannya.
- SOAP: berbasis XML, pesan di dalam envelope; header opsional (kira-kira seperti alamat), body wajib (wadah data sebenarnya). Pesan SOAP satu arah, bukan percakapan. Struktur: Envelope (awal dan akhir pesan), Header (atribut opsional untuk intermediary/endpoint), Body (data XML), Attachment (SOAP with Attachments), RPC interaction, Encoding.
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<soap:Header> ... </soap:Header>
<soap:Body> ... </soap:Body>
</soap:Envelope>- WSDL, empat bagian: (1) Types (tipe data abstrak dalam XML); (2) Interfaces (operasi dan urutannya; pola one-way endpoint menerima pesan, request-response menerima lalu mengirim pesan berkorelasi, solicit-response mengirim lalu menerima, notification mengirim); (3) Bindings (bentuk pesan dan protokol transport); (4) Services (menggabungkan interfaces dan bindings ke endpoint/port).
- UDDI: direktori web service. Tiga bagian: White pages (informasi organisasi yang mempublikasikan service), Yellow pages (informasi deskriptif tiap service), Green pages (informasi teknis untuk terhubung). Impian awal: satu registry global; kenyataan: banyak registry dengan tingkat visibilitas berbeda sehingga ada masalah pemetaan. Alur: Service Provider publish ke Registry; Service Requester search di Registry, lalu (1) bind dan (2) invoke ke Service Provider.
- Policy: model relasi: Service Consumer understands Contracts, adheres to Policy, binds to End Point, sends/receives Messages. Service implements Contracts, exposes End Point, governed by Policy, sends/receives Messages. End Point serves Contracts; Contracts describes Messages. Policy illustrated (Clemens Vasters): policy memuat kemampuan (mis. mendukung X.509 atau Kerberos ST untuk autentikasi, UTF-8, UTF-16, SOAP 1.2 dan 1.1); design time contract adalah kesepakatan fungsional (“kamu kirim PO, saya kirim konfirmasi”); runtime contract adalah pilihan konkret saat berjalan (X.509, UTF-8, SOAP 1.2). “The fact that I can, doesn’t mean I will.”
Arsitektur web service dengan legacy dan composite: service requester berinteraksi lewat mapping layer dan service descriptor dengan service baru, legacy system yang dibungkus (wrapper), dan composition engine yang menggabungkan service menjadi composite service.
2.7 Service Composition: Orchestration vs Choreography
Sumber: 2_SOA dan Web Service (memakai 2.6)
| Aspek | Orchestration | Choreography |
|---|---|---|
| Definisi | Satu proses bisnis eksekutabel tersentralisasi (orchestrator/composite service) yang mengoordinasikan interaksi antar service | Deskripsi global service yang berpartisipasi, ditentukan oleh pertukaran pesan, aturan interaksi, dan kesepakatan antar dua atau lebih endpoint |
| Pendekatan | Tersentralisasi; orchestrator meng-invoke dan menggabungkan hasil; relasi digambarkan lewat satu endpoint (composite service) | Desentralisasi; semua service setara, tanpa titik kontrol |
| Bahasa | WS-BPEL / BPEL4WS (executable model), contoh engine Apache ODE; dapat dieksekusi | WS-CDL; tidak dapat dieksekusi |
| Cakupan | Aksi komunikasi dan aksi internal (transformasi data, pemanggilan modul internal) | Tidak mendeskripsikan aksi internal yang tidak berefek eksternal; menangkap interaksi dan dependensi (control-flow, data-flow, message correlation, batas waktu, transaksional) dari perspektif global |
- BPEL4WS: tiga bagian utama: partner links (dependensi antar service: siapa mengirim apa ke siapa), global variables, workflow model (“program”).
- Behavioural interface (abstract process di BPEL): menangkap dependensi perilaku antar interaksi yang diikuti sebuah service (mis. setiap query dari service lain harus dibalas response).
- Service orchestration, tiga layer: orchestration/coordination layer (urutan logis), business services layer, infrastructure service layer; terhubung lewat service bus secara fisik.
2.8 Siklus Hidup, Analisis, dan Prinsip Desain SOA
Sumber: 5_SOA Design Principles (memakai 2.2 sampai 2.5)
Domain logika: business logic (business processes: kumpulan task, keputusan) dan application logic (terikat aplikasi A, B, C). Service interface layer (abstraction) berada di antara business process layer dan application layer, merepresentasikan service secara abstrak sehingga business process “melihat” service tanpa peduli implementasi aplikasi di baliknya.
SOA delivery lifecycle:
| Top-down (mulai dari nol) | Bottom-up (dari aplikasi yang ada) |
|---|---|
| 1. Define relevant ontology | 1. Model application services |
| 2. Align relevant business models | 2. Design application services |
| 3. Perform service-oriented analysis | 3. Develop application services |
| 4. Perform service-oriented design | 4. Test services |
| 5. Develop services | 5. Deploy services |
| 6. Test service operations | |
| 7. Deploy services |
SOA analysis: tujuan menentukan service apa yang dibangun dan logika/proses/rutin apa yang dienkapsulasi tiap service. Langkah: (1) definisikan set awal kandidat service; (2) kelompokkan kandidat operasi ke konteks logis (konteks = kandidat service); (3) definisikan batas service awal agar tidak tumpang tindih; (4) identifikasi logika terenkapsulasi yang potensial reuse; (5) pastikan konteks logika sesuai tujuan penggunaan; (6) definisikan model komposisi awal yang diketahui.
Define service candidates: Top-down: definisikan business requirements, identifikasi sistem otomasi, model kandidat service. Bottom-up: memakai BPM (task-centric: turunkan business service untuk mendukung sub-proses) atau Entity Model (entity-centric: turunkan primitif yang dilakukan entitas). Contoh task-centric: Invoice Submission, Order Fulfillment, TLS Subscription Service; entity-centric: Accounts Payable, Vendor Profile, Purchase Order, Ledger Service.
Delapan prinsip desain SOA (Thomas Erl; mnemonic SLAR ASDC):
| # | Prinsip | Isi |
|---|---|---|
| 1 | Reusable | Terlepas ada tidaknya kesempatan reuse langsung, service didesain mendukung potential reuse di masa depan (satu service di service interface layer terhubung ke banyak bagian business process layer) |
| 2 | Shares a formal contract (Standardized Service Contract) | Agar berinteraksi, service tidak perlu berbagi apa pun selain kontrak formal yang mendeskripsikan service dan syarat pertukaran informasi |
| 3 | Loosely coupled | Interaksi tanpa dependensi ketat lintas service; underlying logic tetap dihubungkan lewat kontrak |
| 4 | Abstracts underlying logic | Hanya yang diekspos kontrak yang terlihat dari luar; logika di baliknya tidak terlihat dan tidak relevan bagi requestor |
| 5 | Composable | Service boleh mengomposisi service lain; logika bisa direpresentasikan dalam berbagai granularitas, mempromosikan reusability dan abstraction layers |
| 6 | Autonomous | Logika yang diatur service berada dalam batas eksplisit; service punya kontrol dalam batas itu dan tidak bergantung pada service lain untuk governance-nya |
| 7 | Stateless | Service tidak seharusnya mengelola state (menghambat loose coupling); memaksimalkan statelessness, mis. state didelegasikan lewat token seperti JWT |
| 8 | Discoverable | Deskripsi service dapat ditemukan dan dipahami manusia maupun requestor lain (mis. lewat service registry) |
Ringkasan tujuan dan contoh implementasi: Standardized Contract (integrasi mudah; protokol konsisten REST/SOAP plus format XML/JSON); Loose Coupling (fleksibilitas, maintainability, fault tolerance; service independen lewat message broker seperti RabbitMQ, Kafka); Abstraction (information hiding); Reusability (kurangi duplikasi; service generik); Autonomy (reliabilitas dan kinerja; resource sendiri per service); Statelessness (skalabilitas dan maintainability; JWT tanpa session state); Discoverability (mudah ditemukan tanpa proses manual; service registry); Composability (dikombinasikan untuk proses bisnis lebih besar).
2.9 Microservices
Sumber: 4_Microservices (memakai 2.2 sampai 2.8)
Microservice architectural style: satu aplikasi sebagai suite service kecil independen; tiap service berjalan di proses sendiri, berkomunikasi lewat mekanisme ringan (sering HTTP resource API), dibangun di sekitar kapabilitas bisnis, dapat di-deploy independen dengan mesin otomasi deployment penuh, dengan manajemen data terdesentralisasi minimal. Cerita sukses mis. Netflix.
| Monolithic | Kelebihan | Kekurangan (pain points) |
|---|---|---|
| Dibangun sebagai satu unit (single codebase); perubahan apa pun melibatkan build dan deploy seluruh aplikasi; scaling dengan mereplikasi seluruh aplikasi | Codebase tunggal (mudah dikembangkan, dukungan IDE); mudah scale horizontal; biaya pengembangan dan maintenance lebih rendah; lebih cepat dan sederhana di awal | Change cycle semua fitur terikat jadi satu; scaling sulit granular per komponen; availability bermasalah karena tight coupling; codebase besar tanpa ownership jelas, siklus deployment panjang |
Karakteristik microservice: komponen di-deploy terpisah (componentization via services); infrastructure automation (mendukung Continuous Integration dan Continuous Delivery); decentralized data management (database per service, bounded context; super decoupled, mungkin butuh replikasi data); sering containerized; desain: smart endpoints, dumb pipes (logika di service, bukan di pipe/middleware; kebalikan ESB tradisional), API publik simple dan stateless (RESTful), bullet proof, designed from the outside, self-described, reuse tinggal konfigurasi, platform agnostic, siap menghadapi perubahan konstan, self service. Dua konsep yang unik dibanding SOA monolitik klasik: (1) distributed/separately deployed (didukung CI/CD) dan (2) decentralized data management.
Infrastructure automation: pipeline otomasi mencakup compile, unit dan functional test, acceptance test, integration test, user acceptance test, dan performance test.
Orchestration pada microservices: service orchestration tidak lebih disukai (not preferred); yang umum adalah broker/service discovery agent dan/atau Message Queue, bukan satu orchestrator terpusat seperti BPEL.
Gaya komunikasi:
| Gaya | Deskripsi | Karakteristik |
|---|---|---|
| Synchronous blocking | Membuat call dan memblok operasi menunggu response | Request-response via HTTP; sederhana tetapi bisa membentuk rantai call panjang |
| Asynchronous non-blocking | Service pengirim tetap bisa lanjut walau call belum diterima | Request-response (meminta sesuatu dan mengharapkan response) atau event-driven (service memancarkan event, service lain subscribe dan bereaksi); cocok untuk proses kompleks yang tidak butuh jawaban cepat |
Aplikasi microservice harus di-design for failure (kegagalan salah satu service adalah keniscayaan). Lihat juga pola Circuit Breaker di 13_SOA Performance, Scalability & Availability.
Tantangan: management yang baik; service discovery yang baik (lokasi service dinamis, terutama di container/cloud); fan out yang bisa sangat banyak dan crowded (satu request memicu panggilan berantai); dependency antar service harus dikelola; data serialization overhead.
2.10 Cloud Computing
Sumber: 10_Cloud Computing (memakai 2.2 dan 2.9)
Motivasi provisioning tradisional: butuh capital outlay besar untuk hardware, SDM terampil, ada risiko over-provisioning (kapasitas terbuang) dan under-provisioning (kehilangan calon pengguna). Cloud memungkinkan mulai kecil dan tumbuh sesuai kebutuhan.
(Grafik: (a) provisioning for peak load, area di atas demand adalah kapasitas tak terpakai; (b) underprovisioning, area di atas kapasitas adalah request tak terlayani; (c) underprovisioning, permintaan menurun karena pengguna pergi.) Realita: utilisasi server rata-rata 5%-20%; beban puncak melebihi rata-rata 2-10 kali; pengguna cenderung provisioning untuk puncak; puncak bisa terjadi menurut waktu (mis. foto sharing setelah liburan, drop/add dua minggu awal semester). Untuk batch-oriented besar: 1000 server selama 1 jam biayanya tidak lebih dari 1 server selama 1000 jam, derajat elastisitas yang belum pernah ada dalam sejarah IT.
Definisi: istilah umum untuk kelas baru komputasi berbasis jaringan di atas Internet, kelanjutan Utility Computing; sekumpulan hardware, software, dan infrastruktur internet terintegrasi (disebut platform); layanan on-demand, selalu aktif di mana saja kapan saja; pay for use; elastic (scale up/down kapasitas dan fungsionalitas). Alur nilai: Cloud Provider menyediakan utility computing ke SaaS Provider / Cloud User, yang menyediakan web applications ke SaaS User (slide diadaptasi dari “A View of Cloud Computing”, Armbrust dkk., UC Berkeley).
Tiga aspek baru: (1) ilusi resource komputasi tak terbatas on-demand (tanpa provisioning jauh-jauh hari); (2) eliminasi komitmen di muka oleh pengguna cloud (mulai kecil dan tumbuh); (3) membayar resource jangka pendek sesuai kebutuhan (reward conservation).
Key enablers: datacenter skala sangat besar berbasis commodity computer di lokasi berbiaya rendah; statistical multiplexing untuk meningkatkan utilisasi (“to each according to his needs”), berubah seiring waktu, beda dari hosting tradisional; virtualisasi komputasi, penyimpanan, dan komunikasi.
| Kategori | Definisi | Contoh | Fleksibilitas |
|---|---|---|---|
| SaaS | Pengguna langsung memakai aplikasi tanpa kelola infrastruktur/platform | Dropbox, Salesforce | Hampir tidak fleksibel (sebatas kustomisasi tema dan API) |
| PaaS | Platform untuk membangun dan mengembangkan aplikasi tanpa kelola server | Google AppEngine, Microsoft Azure | AppEngine: paling tidak fleksibel (platform domain-spesifik, auto-scaling, high availability, proprietary megastore, bukan untuk general purpose). Azure: moderat (platform pengembangan software language independent, .NET dan library .NET, general purpose di platform Microsoft) |
| IaaS | Infrastruktur virtual (server, storage) | Amazon EC2 | Sangat fleksibel (hardware virtual machine, pilih OS dan seluruh software stack, kelola dari kernel ke atas) |
Makin ke IaaS makin fleksibel tetapi makin besar tanggung jawab pengelolaan pengguna.
Top 10 obstacles:
- Business continuity and service availability: apakah provider bertahan lama? bisakah mencegah single point of failure dengan lebih dari satu provider?
- Data lock-in: penyimpanan cloud pada dasarnya proprietary; SaaS developer sulit memindahkan data ke cloud lain; solusi standarisasi API data.
- Data confidentiality/auditability: keamanan jadi keberatan paling sering (HIPAA, Sarbanes-Oxley); masalah lama, tetapi di cloud lebih banyak pihak terlibat; penulis menilai tidak lebih sulit daripada datacenter tradisional.
- Data transfer bottlenecks: $100-150 per TB (mengirim disk fisik kadang lebih murah); pembanding 2010: Library of Congress ~235 TB, Wikipedia ~5,87 TB, Watson 16 TB RAM; 1 TB ~10^12 byte.
- Performance unpredictability: VM berbagi CPU dan memori dengan baik, tetapi I/O jaringan dan disk kurang bisa diprediksi; VM bukan hal baru (IBM 1980-an); flash memory jauh lebih cepat dan bisa mengurangi interferensi I/O.
- Scalable storage: riset terbuka: storage yang memenuhi ekspektasi durability, high availability, dan kemampuan query sambil scale elastis (AWS EBS dan SimpleDB; Azure SQL Data Services dan Azure Storage Service; AppEngine Megastore/BigTable; proyek NoSQL open source).
- Bugs in large-scale distributed systems: mis. berita 25 April 2011, Amazon menyatakan sebagian kecil data hilang tidak akan sepenuhnya dipulihkan.
- Scaling quickly: pay-as-you-go untuk storage dan bandwidth; AppEngine scale otomatis; AWS menagih per jam per instance walau idle; tantangan scale cepat naik dan turun tanpa melanggar SLA.
- Reputation fate sharing (“one bad apple spoils the bunch”): IP EC2 masuk blacklist spam; FBI menggerebek data center Dallas karena satu penyewa, sehingga penyewa tak bersalah mati berhari-hari dan sebagian bangkrut.
- Software licensing: lisensi tradisional membatasi komputer tempat software berjalan dan dijual dengan biaya pemeliharaan, bukan pay-as-you-go; Microsoft dan IBM mulai menawarkan pay-as-you-go (2011: IBM $6,39 per jam untuk WebSphere dengan Lotus Web Content Management di EC2).
SOA dan cloud (Linthicum): “While you can certainly leverage a cloud without practicing SOA, and you can leverage SOA without leveraging cloud computing, the real value of cloud computing is the ability to use services, data, and processes that can exist outside of the firewall…” Nilai inti: cloud memperluas jangkauan SOA melampaui batas organisasi.
2.11 Mitos tentang SOA
Sumber: 17_Myth of SOA (memakai 2.2 sampai 2.9)
| # | Mitos | Fakta |
|---|---|---|
| 1 | SOA menyediakan arsitektur lengkap sistem | SOA hanya pattern/style, bukan arsitektur sistem. Elemen konkret dan interaksinya adalah arsitektur; SOA mewarisi sisi baik dan buruk pattern; tidak bisa dibeli jadi; kualitas harus dibangun dan keputusan (desain service, teknologi, trade-off) harus diambil |
| 2 | Sistem legacy mudah diintegrasikan | Perlu analisis di awal: kelayakan teknis membuat service dari legacy, biaya membukanya sebagai service, apakah biaya itu ditambah pemeliharaan melebihi biaya menggantinya, perubahan yang diperlukan, dampak ke pengguna dan sistem produksi lain |
| 3 | SOA hanya soal standar dan standar saja cukup | Berasal dari salah paham SOA = Web Services. Standar dasar (WSDL, SOAP, XML) stabil; standar tingkat tinggi belum matang; terlalu banyak standar yang tumpang tindih (WSCL vs WS-Coordination, SAML vs WS-Security). “The good thing about standards is that there are so many to choose from” |
| 4 | XML dan WSDL menjamin interoperabilitas | Hanya menjamin syntactic interoperability (XML Schema: struktur dan tipe data; WSDL: operasi, parameter, nilai kembalian). Tidak menjamin semantic (makna data, apa yang dilakukan service); area riset aktif. Butuh kesepakatan sintaks dan semantik |
| 5 | SOA hanya soal teknologi | Juga perubahan model governance: definisi service, repositori, kepemilikan (service/data bersama milik siapa), evolusi, penyelesaian konflik, mekanisme deployment dan monitoring, kebijakan enterprise, SLA |
| 6 | Mudah membangun aplikasi berbasis service | Implementasi: bergantung tools infrastruktur, bagian tersulit komposisi (data tidak cocok). Desain: sedikit best practice, harus mengantisipasi pengguna dan pola pemakaian, QoS yang tepat dan bisakah dijamin, risiko “if you build it they will come” |
| 7 | Mudah menyusun service dinamis saat runtime | Teknologi belum cukup maju untuk produksi; butuh ontologi bersama dan aplikasi sangat cerdas (membuat query discovery yang tepat, mengomposisi bila tidak ada satu service yang cukup, menyediakan data yang benar untuk memanggil service yang ditemukan saat runtime) |
| 8 | Pengujian tidak berbeda | Sistem terdistribusi; tidak ada kontrol atas service eksternal (black box, butuh exception management “What if the service disappears?”, QoS bervariasi menurut beban); developer harus mengantisipasi pola pemakaian |
Mitos tambahan (Erl, 2008): aplikasi yang memakai Web services otomatis berorientasi service; SOA hanya istilah marketing untuk me-rebrand web service; SOA hanya istilah marketing untuk me-rebrand distributed computing dengan Web services; SOA menyederhanakan distributed computing; aplikasi dengan Web services yang memakai ekstensi WS-* otomatis berorientasi service; jika paham Web services pasti tidak bermasalah membangun SOA; begitu memakai SOA semuanya interoperable.
Ringkasan: gunakan SOA dengan hati-hati. SOA bisa jadi cara terbaik mencapai interoperability, agility, dan reuse, tetapi sebagian besar isu adalah area riset aktif dan butuh waktu matang. Tidak semua hal dalam sistem SOA harus berupa service, dan kunci keberhasilan adalah governance, yang hampir tidak berhubungan dengan teknologi.
Bahan diskusi kelompok (slide W01b, “Myth Busting”): SOA vs Microservice (lihat 2.9) dan SOAP vs REST (lihat 2.6 dan 2.9).
3. Sengaja Tidak Dicakup (Rinci di Note Sumber)
| Yang dilewati | Ada di |
|---|---|
| Diagram Mermaid orchestration dan choreography (digambarkan dengan teks di 2.7) | 2_SOA dan Web Service |
| Detail seluruh flashcard asli tiap note (tetap di note sumber supaya kartu plugin tidak dobel) | masing-masing note |
| Slide W03 (BPM dan BPMN), design patterns, SoaML, integration, GraphQL, WSLA, performance, testing, security | note 3, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16 (tidak ada di zip) |
4. Peta Pembahasan
| Note sumber | Topik | Bagian di file ini |
|---|---|---|
| 1 | Definisi service, service computing, SOA, vision, triangle, ingredients, OO | 2.1, 2.2 |
| 2 | Evolusi, integrasi, interoperability, operasi dasar, registry, invocation, manfaat | 2.3, 2.4 |
| 2 | Service models, shared resource, contract decoupling | 2.5 |
| 2 | Web service, XML, SOAP, WSDL, UDDI, policy | 2.6 |
| 2 | Orchestration vs choreography, BPEL, behavioural interface | 2.7 |
| 5 | Lifecycle, analysis, service candidates, 8 prinsip | 2.8 |
| 4 | Microservices, monolith vs microservice, komunikasi, tantangan | 2.9 |
| 10 | Provisioning, definisi, SaaS/PaaS/IaaS, top 10 obstacles, SOA dan cloud | 2.10 |
| 17 | Delapan mitos CMU, mitos Erl, ringkasan | 2.11 |