Analisis Soal UTS KomLay
Pendamping UTS_KomLay. Isinya: analisis soal tahun-tahun sebelumnya, semua soal lama yang relevan dengan cakupan UTS tahun ini beserta jawabannya, dan soal prediksi untuk materi yang belum pernah ditanyakan.
Sumber soal: _Materi/KomLay/Soal.md. Menurut catatan di file itu, soalnya direkonstruksi dari ingatan setelah ujian, jadi kalimat soal bisa sedikit berbeda dari aslinya.
Cakupan: sama persis dengan UTS_KomLay, yaitu note 1, 2, 4, 5, 10, 17, 18, 19, 20. Tidak ada materi tambahan. Jawaban merujuk ke nomor bagian di UTS_KomLay (mis. “2.7”). Penjelasan yang tidak ada di catatan diberi tanda (tambahan).
1. Sumber Soal
| Set | Jenis | Tahun | Jumlah soal |
|---|---|---|---|
| A | UTS | tidak disebut (lebih lama) | 5 esai + studi kasus TokoLapak (BPMN dan desain RESTful) |
| B | UAS | tidak disebut (lebih lama) | 4 jawaban singkat + studi kasus LMS |
| C | UTS | 2025/2026 (tahun lalu) | 6 esai |
Set B adalah soal UAS, tetapi sebagian topiknya (cloud, microservice, desain service) masuk cakupan UTS tahun ini, jadi ikut dianalisis.
2. Analisis
2.1 Pemetaan Soal Lama ke Cakupan Tahun Ini
| Kode | Soal (ringkas) | Topik | Masuk cakupan 2026? | Bagian |
|---|---|---|---|---|
| A1 | 2 perbedaan service registry dan broker/service bus | Registry, invocation, ESB | Ya | 2.4, 2.5 |
| A2 | Keuntungan dan kerugian orchestration vs choreography | Composition | Ya | 2.7 |
| A3 | Mitos “XML dan WSDL menjamin interoperability” | Mitos SOA | Ya | 2.11 |
| A4 | 3 dari 8 design principles dan contoh | Prinsip desain | Ya | 2.8 |
| A5 | 2 konsep baru microservice dibanding SOA monolitik | Microservice | Ya | 2.9 |
| A6–A9 | BPMN checkout TokoLapak; desain RESTful ShippingCalculatorService dengan UML/SoaML | BPMN (W03), SoaML (W07) | Tidak | — |
| B1 | Message integrity vs message authentication, dan SOA pattern-nya | Security (W15) | Tidak | — |
| B2 | 3 keunggulan cloud dibanding on-premise dan catatannya | Cloud | Ya | 2.10, 2.12 |
| B3 | 3 karakter microservice dibanding SOA klasik dan dampaknya ke pembangunan | Microservice | Ya | 2.9 |
| B4 | Teknik testing untuk dependensi lambat atau kompleks | Testing (W14) | Tidak (mitos 8 hanya menyinggung) | — |
| B5 | Rancangan arsitektur berorientasi service untuk LMS | Taksonomi dan prinsip | Ya (bagian konsep) | 2.5, 2.8 |
| B6–B7 | Transformasi LMS ke microservice dan dampaknya | Microservice | Ya | 2.9, 2.10 |
| B8 | Reporting lintas service: aggregate call vs pub/sub | Komunikasi microservice | Ya (sebagian) | 2.9 |
| C1 | Orchestration vs choreography, kapan dipakai, pertimbangannya | Composition | Ya | 2.7, 2.9 |
| C2 | Fungsi WSDL, pengaruhnya ke provider dan requester, dan di REST | Web service | Ya (bagian REST tambahan) | 2.6 |
| C3 | 3 dari 8 design principles dan contoh | Prinsip desain | Ya | 2.8 |
| C4 | Chattiness dan fan out pada microservice, contoh ekstrem | Microservice | Ya (chattiness tambahan) | 2.9 |
| C5 | Request diproses 30 detik; pattern agar klien tidak timeout | Komunikasi async | Ya (nama pattern dari note 6) | 2.9 |
| C6 | Service validasi KTP/telepon untuk banyak aplikasi; pattern yang cocok | Taksonomi dan prinsip | Ya (nama pattern dari note 6) | 2.5, 2.8 |
2.2 Pola Soal (Behavior)
Topik yang muncul berulang:
- Orchestration vs choreography muncul di kedua UTS (A2, C1). Yang ditanya bukan definisi saja, tetapi kelebihan, kekurangan, dan kapan dipakai.
- 3 dari 8 design principles dengan contoh muncul di kedua UTS (A4, C3), dengan kalimat soal yang hampir sama. Peluang muncul lagi sangat besar.
- Microservice dibanding monolith/SOA klasik muncul tiga kali (A5, B3, C4) dari sudut berbeda: konsep unik, dampak ke pembangunan, dan tantangan (fan out).
- Satu soal konsep dasar SOA/web service selalu ada, dengan topik berganti: registry vs broker (A1), mitos XML/WSDL (A3), WSDL (C2).
- Studi kasus penerapan selalu ada: skenario bisnis lalu diminta merancang atau memilih solusi dan memberi alasan (A6–A9, B5–B8, C5–C6).
Bentuk kalimat soal:
- “Sebutkan N dan jelaskan”, sering ditambah “berikan contoh/ilustrasi”.
- “Bandingkan”, dengan “keuntungan dan kerugian masing-masing”.
- “Kapan/dalam situasi apa dipakai dan apa pertimbangannya”.
- “Jelaskan dampaknya ke …” (pembangunan sistem, user, scalability).
- Yang dinilai adalah penalaran dan trade-off, bukan hafalan.
Yang tidak pernah ditanyakan (dari tiga set ini saja):
- Definisi kamus “layanan” (KBBI, Oxford, Merriam-Webster) dan analogi (restoran Italia, kupat tahu).
- Sejarah integrasi, angka survei (CIO 2002, Forrester), dan “islands of automation”.
- Detail struktur SOAP envelope, bagian UDDI (white/yellow/green pages), bagian BPEL4WS.
- Angka statistik cloud (utilisasi 5–20%, $100–150 per TB) dan daftar 10 obstacles secara utuh.
- Mitos tambahan versi Erl.
Artinya: materi hafalan dan angka berfungsi sebagai bahan argumen, bukan pertanyaan langsung. Misalnya angka utilisasi 5–20% berguna untuk menjelaskan keunggulan cloud (B2), tetapi tidak pernah ditanya sendiri.
Materi baru tahun ini: catatan 18–20 (cloud cost engineering, pengajar tamu) belum pernah muncul karena memang baru. Cloud sendiri hanya muncul sekali, di UAS (B2), dalam bentuk “keunggulan dan catatannya”.
Perubahan cakupan antar tahun. Materi UTS berubah dari tahun ke tahun, jadi beberapa soal lama memakai topik yang tahun ini tidak masuk UTS: BPMN dan SoaML (set A), security dan testing (set B), serta design pattern (C5 dan C6). Soal yang sepenuhnya di luar cakupan tidak dibahas. C5 dan C6 tetap dibahas karena kasusnya bisa dijawab dengan konsep cakupan tahun ini (komunikasi asynchronous, taksonomi service, dan prinsip desain); nama pattern-nya hanya disebut sebagai rujukan.
2.3 Prioritas Belajar
| Prioritas | Topik | Alasan |
|---|---|---|
| 1 (hampir pasti) | Orchestration vs choreography (definisi, pro/kontra, kapan); 8 prinsip desain dengan contoh; microservice vs monolith/SOA klasik (karakter, dampak, fan out) | Muncul di kedua UTS atau berulang di semua set |
| 2 (sering) | Konsep dasar SOA/web service (registry, broker, WSDL, interoperability, mitos); studi kasus merancang service (taksonomi + prinsip) dan microservice (database per service, sync vs async) | Selalu ada satu soal konsep dasar dan satu studi kasus |
| 3 (mungkin) | Cloud (keunggulan, SaaS/PaaS/IaaS, obstacles), mitos lain, lifecycle dan analysis, cost engineering | Masuk cakupan tetapi belum pernah ditanya di UTS |
3. Soal Lama dan Jawaban
A1. Service registry vs broker/service bus
Soal. Sebutkan 2 perbedaan utama dari service registry dan broker/service bus. Jelaskan secara singkat.
Jawaban.
- Fungsi. Service registry adalah katalog informasi tentang service: deskripsi, kontrak, klasifikasi, riwayat penggunaan, hasil test, metrik performa, dokumentasi. Registry di-query saat service discovery. Broker/service bus adalah perantara komunikasi saat runtime: meneruskan pesan, menerjemahkan format data (contract decoupling, mis. XML SKU+tanggal menjadi product-id+quantity), dan bisa melakukan load balancing.
- Jalur pemanggilan. Dengan registry, requester hanya menanyakan lokasi, lalu memanggil provider secara langsung; pesan request dan response tidak melewati registry. Dengan broker/service bus, requester mengirim request lewat broker, dan broker yang mencari lokasi (bisa ke banyak discovery) serta meneruskan pesan. Requester tidak perlu tahu lokasi provider.
Rujukan: 2.4 (registry, tiga cara invocation), 2.5 (contract decoupling dengan ESB).
A2. Orchestration vs choreography: keuntungan dan kerugian
Soal. Sebutkan masing-masing 2 keuntungan dan kerugian dari orchestration vs choreography.
Jawaban.
| Orchestration | Choreography | |
|---|---|---|
| Keuntungan | (1) Alur proses terpusat dan jelas di satu tempat (orchestrator), sehingga mudah dipahami, dimonitor, dan diubah. (2) Consumer cukup mengenal satu endpoint (composite service); prosesnya dapat dieksekusi (WS-BPEL, mis. Apache ODE) dan bisa mencakup aksi internal seperti transformasi data | (1) Desentralisasi: tidak ada titik kontrol tunggal, jadi tidak ada single point of failure atau bottleneck di pusat. (2) Service lebih otonom dan loosely coupled; peserta baru cukup mengikuti aturan pertukaran pesan |
| Kerugian | (1) Orchestrator menjadi single point of failure dan bottleneck. (2) Latensi bertambah karena semua interaksi melewati orchestrator | (1) Alur global tersebar di banyak service sehingga sulit dilihat dan di-debug; WS-CDL hanya deskripsi, tidak dapat dieksekusi. (2) Semua peserta harus menyepakati pesan, aturan interaksi, dan kontrak; consumer mungkin perlu tahu banyak endpoint (bisa dibantu registry) |
Rujukan: 2.7.
A3. Mitos “XML dan WSDL menjamin interoperability”
Soal. Jelaskan alasan ketidaktepatan pernyataan “Using XML and WSDL guarantees interoperability among web services provided by multiple organizations”.
Jawaban. XML Schema hanya mendefinisikan struktur dan tipe data, dan WSDL hanya mendefinisikan operasi, parameter, dan nilai kembalian. Keduanya menjamin syntactic interoperability: kedua pihak bisa saling mengirim pesan yang formatnya valid. Keduanya tidak menjamin semantic interoperability: arti data dan apa yang sebenarnya dilakukan service.
Contoh (tambahan): dua service sama-sama punya elemen price bertipe decimal. Bagi service A, price adalah rupiah termasuk pajak; bagi service B, dolar sebelum pajak. WSDL keduanya valid dan bisa saling dipanggil, tetapi hasilnya salah. Agar interoperable, organisasi harus menyepakati sintaks dan semantik (mis. lewat ontologi bersama). Semantic interoperability masih area riset aktif.
Rujukan: 2.3 (syntactic vs semantic), 2.11 (mitos 4).
A4 dan C3. Tiga dari delapan design principles dengan contoh
Soal. Sebutkan 3 dari 8 service design principles. Berikan penjelasan dan contoh/ilustrasi untuk masing-masing.
Jawaban. Cukup pilih 3. Semua 8 disiapkan di bawah, dengan contoh pada satu sistem e-commerce supaya mudah diingat.
| Prinsip | Penjelasan | Contoh |
|---|---|---|
| Reusable | Didesain untuk mendukung potensi reuse, walaupun saat ini belum ada pemakai lain | Customer Lookup dipakai Order Processing, Invoicing, dan CRM sekaligus |
| Standardized/formal contract | Service hanya berbagi kontrak formal yang menjelaskan apa yang dilakukan dan cara bertukar informasi | Payment service dideskripsikan dengan WSDL (atau kontrak REST/JSON); consumer cukup membaca kontrak |
| Loosely coupled | Interaksi tanpa dependensi ketat; yang menghubungkan hanya kontrak | Order service mengirim event “order dibuat” lewat message broker (RabbitMQ/Kafka); Inventory bereaksi. Inventory boleh ganti implementasi tanpa mengubah Order |
| Abstract underlying logic | Hanya yang ada di kontrak yang terlihat; logika di dalamnya disembunyikan | Operasi bayar(orderId, jumlah) tidak memperlihatkan bank atau payment gateway mana yang dipakai |
| Composable | Service bisa digabung menjadi service yang lebih besar | Service Checkout adalah komposisi Inventory, Payment, dan Shipping |
| Autonomous | Service punya batas logika yang jelas dan mengendalikan sumber dayanya sendiri | Inventory punya database dan runtime sendiri; perawatannya tidak menunggu service lain |
| Stateless | Service meminimalkan state yang disimpan agar tidak mengganggu loose coupling dan mudah di-scale | Autentikasi memakai token JWT, bukan session di server, sehingga replika mana pun bisa melayani |
| Discoverable | Deskripsi service bisa ditemukan dan dipahami manusia maupun program | Service didaftarkan di service registry sehingga tim lain menemukannya dan tidak membangun ulang |
Tips menjawab: tiap prinsip tulis definisi satu kalimat + manfaatnya + contoh konkret. Hindari menulis “stateless = tidak boleh menyimpan state apa pun”; yang benar adalah meminimalkan state yang dikelola service.
Rujukan: 2.8.
A5. Konsep baru yang unik pada microservice
Soal. Sebutkan dan jelaskan dua konsep baru yang uniquely ada pada microservice dibandingkan dengan monolithic SOA.
Jawaban.
- Distributed dan separately deployed (componentization via services). Tiap service berjalan di prosesnya sendiri dan bisa di-deploy sendiri, tanpa men-deploy seluruh aplikasi. Hal ini didukung infrastructure automation (CI/CD: pipeline compile, unit/functional test, integration test, sampai performance test).
- Decentralized data management. Tiap service mengelola datanya sendiri (database per service, dibatasi bounded context), bukan satu database bersama. Hasilnya service sangat decoupled, dengan konsekuensi mungkin butuh replikasi data.
Alternatif jawaban: smart endpoints, dumb pipes (logika ada di service, jalur komunikasinya sederhana; kebalikan ESB pada SOA klasik).
Rujukan: 2.9.
B2. Keunggulan cloud dibanding on-premise, beserta catatannya
Soal. Jelaskan tiga aspek keunggulan cloud computing dibandingkan model on-premise tradisional. Ulaskan constraint atau catatan untuk keunggulan tersebut.
Jawaban.
| Keunggulan | Penjelasan | Catatan/constraint |
|---|---|---|
| Elastis: ilusi resource tak terbatas | Kapasitas bisa ditambah atau dikurangi sesuai permintaan, sehingga tidak perlu provisioning untuk beban puncak. On-premise rawan over-provisioning (utilisasi server hanya 5–20%) atau under-provisioning (pengguna pergi) | Aplikasi harus dirancang bisa scale; scale cepat naik-turun tanpa melanggar SLA masih tantangan (scaling quickly); performa I/O VM tidak selalu bisa diprediksi |
| Tanpa komitmen di muka (CapEx menjadi OpEx) | Bisa mulai kecil dan tumbuh; tidak perlu modal besar untuk server, rack, dan SDM sejak awal | Untuk beban tetap jangka panjang, tagihan bisa lebih mahal: hitung TCO, bandwidth/egress, dan biaya idle. Ada risiko data lock-in dan isu lisensi software |
| Bayar sesuai pemakaian jangka pendek | Pekerjaan batch besar bisa diselesaikan cepat: 1000 server selama 1 jam biayanya tidak lebih dari 1 server selama 1000 jam | Memindahkan data besar mahal dan lambat (data transfer bottleneck); data sensitif menyentuh isu kerahasiaan dan audit (HIPAA, Sarbanes-Oxley) |
Rujukan: 2.10 (tiga aspek baru, provisioning, obstacles), 2.12 (TCO, cost-aware).
B3. Tiga karakter microservice dan dampaknya ke pembangunan sistem
Soal. Sebutkan 3 karakter microservice dibandingkan classical/monolithic SOA. Jelaskan dampaknya pada fase pembangunan sistem.
Jawaban.
- Separately deployed per service. Dampak: tiap tim bisa merilis service-nya sendiri dengan siklus pendek, tanpa build dan deploy ulang seluruh aplikasi. Konsekuensinya wajib ada infrastructure automation (CI/CD dan test otomatis).
- Decentralized data management. Dampak: tim bebas memilih model dan teknologi data, dan perubahan skema bersifat lokal. Konsekuensinya konsistensi data dan query lintas service (mis. laporan) menjadi lebih sulit dan mungkin butuh replikasi data.
- Smart endpoints, dumb pipes; komunikasi ringan; orchestration terpusat tidak disukai. Dampak: logika bisnis ditulis di service dan komunikasi memakai HTTP/REST atau message queue, bukan ESB atau orchestrator BPEL. Konsekuensinya developer harus mengurus service discovery, fan out, serialisasi data, dan merancang untuk kegagalan (design for failure).
Rujukan: 2.9.
B5. Rancangan arsitektur berorientasi service untuk LMS
Soal (ringkas). Sistem perpustakaan LMS: pustakawan mengelola koleksi (tambah, ubah, hapus, lihat status pinjam/reservasi); pengunjung registrasi, mencari, browsing, meminjam, mengembalikan, reservasi dan membatalkan; pemesan pertama diberi notifikasi saat item tersedia; ada reporting statistik koleksi dan peminjam. Buat rancangan arsitektur berorientasi service, spesifikasi tiap service, dan terapkan kriteria “good service”.
Jawaban. Pecah dengan taksonomi task/entity/utility (2.5):
| Service | Tipe | Operasi utama |
|---|---|---|
| ItemService | Entity | addItem, updateItem, deleteItem, getItem, searchItems, browseItems, getItemStatus |
| MemberService | Entity | register, getMember, updateMember |
| LoanService | Task | borrow(memberId, itemId), return(loanId), getLoans(memberId) |
| ReservationService | Task | reserve(memberId, itemId), cancel(reservationId), onItemAvailable(itemId) (beri tahu pemesan pertama) |
| ReportService | Task | getCollectionStats(periode), getBorrowerStats(periode) |
| NotificationService | Utility | send(memberId, pesan, kanal) |
| AuthService | Utility | login, validateToken, cek peran (pustakawan/pengunjung) |
Alur penting: return di LoanService mengubah status item lewat ItemService, lalu ReservationService memeriksa antrean dan memanggil NotificationService untuk pemesan pertama.
Penerapan kriteria good service (2.8):
- Reusable: ItemService dipakai aplikasi pengunjung, pustakawan, dan ReportService.
- Contract: tiap service punya kontrak formal (WSDL atau kontrak REST).
- Loose coupling: LoanService mengirim event “item dikembalikan”; ReservationService bereaksi tanpa LoanService tahu detailnya.
- Abstraction dan autonomous: tiap service menyembunyikan datanya dan mengelola sumber dayanya sendiri.
- Composable: proses peminjaman adalah komposisi Member, Item, dan Loan.
- Stateless: autentikasi dengan token, bukan session.
- Discoverable: semua service terdaftar di service registry.
Untuk gambar: aplikasi mobile (pengunjung, pustakawan) di atas, lapisan task service di tengah, lalu entity dan utility service di bawah, dengan service registry di samping.
B6–B7. Transformasi LMS ke microservice dan dampaknya
Soal (ringkas). Sistem tumbuh dan melayani banyak perpustakaan fakultas; user sangat banyak dan transaksi per jenis sangat bervariasi. Rancang arsitektur microservice, termasuk letak database, dengan memperhatikan scalability, reliability, complexity, dan security. Jelaskan dampak dan kekurangannya.
Jawaban.
- Pemecahan: satu microservice per kapabilitas bisnis (Catalog/Item, Member, Loan, Reservation, Notification, Report, Auth). Masing-masing di-deploy terpisah, idealnya dalam container.
- Database: database per service (decentralized data management). Tidak ada database bersama; service lain mengakses data hanya lewat API atau event.
- Komunikasi: query sederhana memakai HTTP/REST synchronous; kejadian seperti “item dikembalikan” dikirim sebagai event lewat message queue (asynchronous) sehingga Notification dan Reservation bereaksi tanpa memperlambat Loan.
- Pintu masuk (tambahan): satu API gateway di depan untuk routing dan autentikasi.
| Aspek | Dampak positif | Kekurangan |
|---|---|---|
| Scalability | Service yang trafiknya bervariasi (pencarian katalog, peminjaman awal semester) di-scale sendiri, horizontal, memakai elastisitas cloud | Perlu orkestrasi container dan service discovery karena lokasi service dinamis |
| Reliability | Kegagalan Notification tidak menghentikan peminjaman; replika per service | Kegagalan menjadi keniscayaan sehingga harus design for failure; fan out menambah titik gagal |
| Agility | Tiap tim merilis service-nya sendiri lewat CI/CD | Butuh pipeline otomatis dan versioning kontrak |
| Complexity | Codebase per service kecil dan jelas pemiliknya | Sistem secara keseluruhan lebih kompleks: banyak service, jaringan, monitoring, konsistensi data antar database |
| Security | Akses per service bisa dibatasi; token stateless | Permukaan serangan lebih luas karena banyak endpoint |
B8. Reporting lintas service: aggregate call vs pub/sub
Soal (ringkas). Karena database tersegregasi, reporting lintas service sulit. Tambahkan centralized reporting service dengan dua pendekatan: (a) aggregate call ke tiap microservice, (b) event-driven dengan pub/sub. Sebutkan kakasnya.
Jawaban.
| (a) Aggregate call | (b) Event-driven pub/sub | |
|---|---|---|
| Cara kerja | ReportService memanggil API Loan, Item, dan Member secara synchronous saat laporan diminta, lalu menggabungkan hasilnya | Loan, Item, dan Member mem-publish event (pinjam, kembali, anggota baru) ke message broker; ReportService subscribe dan menyimpan salinan data di database laporannya sendiri |
| Kakas | HTTP/REST | Message broker, mis. RabbitMQ atau Kafka |
| Kelebihan | Sederhana; data selalu terbaru | Service sumber tidak terbebani saat laporan dibuat; sangat loosely coupled; laporan cepat |
| Kekurangan | Fan out ke banyak service, latensi tinggi, membebani service operasional; satu service mati membuat laporan gagal | Data laporan eventually consistent (bisa sedikit tertinggal); infrastruktur lebih kompleks; data terduplikasi |
Rujukan: 2.9 (synchronous vs asynchronous event-driven, fan out), 2.8 (message broker RabbitMQ/Kafka sebagai contoh loose coupling).
C1. Orchestration vs choreography: kapan dipakai
Soal. Jelaskan service orchestration dan choreography, serta kapan atau dalam situasi apa masing-masing dipakai dan pertimbangannya.
Jawaban.
- Orchestration: satu proses terpusat (orchestrator/composite service) yang memanggil service lain secara berurutan dan menggabungkan hasilnya. Bisa dieksekusi (WS-BPEL).
- Choreography: deskripsi global interaksi antar service yang setara, ditentukan oleh pertukaran pesan dan aturan interaksi, tanpa pengendali pusat (WS-CDL, tidak dieksekusi).
| Pakai orchestration jika | Pakai choreography jika |
|---|---|
| Proses butuh urutan ketat, kontrol, dan penanganan kesalahan terpusat (mis. checkout: cek stok, bayar, kirim) | Banyak peserta independen yang cukup bereaksi pada kejadian (mis. setelah order dibuat, inventory, notifikasi, dan analitik bereaksi sendiri) |
| Prosesnya dimiliki satu organisasi atau tim | Lintas organisasi tanpa satu pemilik proses |
| Perlu monitoring jelas di satu tempat | Mengutamakan skalabilitas dan menghindari single point of failure; pada microservice, orchestration terpusat tidak disukai, lebih umum broker atau message queue |
Pertimbangan: coupling ke pusat vs tersebar, single point of failure, kemudahan melihat dan men-debug alur, latensi, dan seberapa sering alur berubah.
Rujukan: 2.7, 2.9.
C2. Fungsi WSDL dan pengaruhnya
Soal. Jelaskan fungsi WSDL, pengaruhnya pada service provider dan service requester, dan bagaimana jika layanan berada di arsitektur REST.
Jawaban.
- Fungsi: WSDL adalah kontrak formal dalam XML yang mendeskripsikan service. Empat bagian: Types (tipe data), Interfaces (operasi dan pola pesannya: one-way, request-response, solicit-response, notification), Bindings (format pesan dan protokol transport), Services (alamat endpoint).
- Pengaruh pada provider: provider wajib menerbitkan dan menjaga kontrak itu. Implementasi boleh berubah selama kontrak tetap (abstraction), tetapi perubahan kontrak berdampak ke semua consumer.
- Pengaruh pada requester: requester tahu cara memanggil service tanpa melihat implementasinya; cukup membaca WSDL (biasanya ditemukan lewat UDDI/registry). Dari WSDL, kode pemanggil bisa dibuat otomatis (tambahan).
- Di REST (tambahan): service REST umumnya tidak memakai WSDL. Kontraknya adalah URI resource, metode HTTP, dan format representasi (biasanya JSON), yang didokumentasikan dengan standar seperti OpenAPI (Swagger) atau WADL. Prinsip standardized service contract tetap berlaku: tetap perlu kontrak yang jelas, hanya bentuknya berbeda. Slide web service stack bahkan masih menandai REST dengan tanda tanya.
Rujukan: 2.6, 2.8.
C4. Chattiness dan fan out
Soal. Jelaskan prinsip chattiness dan fan out pada microservice. Berikan contoh ekstrem fan out yang dipicu oleh seorang user dan dampaknya ke user.
Jawaban.
- Fan out: satu request user memicu panggilan berantai ke banyak service, dan service itu memanggil service lain lagi. Di catatan, fan out disebut salah satu tantangan microservice karena bisa “sangat banyak dan crowded”.
- Chattiness (tambahan): komunikasi yang terlalu “cerewet”, yaitu banyak panggilan kecil (fine-grained) bolak-balik untuk menyelesaikan satu pekerjaan. Tiap panggilan membawa ongkos jaringan dan serialisasi data.
- Contoh ekstrem: user membuka halaman produk di e-commerce microservice. Halaman memanggil Product, Price, Stock, Review, Recommendation, Promo, Seller, dan Shipping. Review lalu memanggil User service satu kali untuk tiap reviewer, dan Recommendation memanggil Profile dan History. Satu klik bisa menjadi puluhan sampai ratusan panggilan internal.
- Dampak ke user: halaman lambat, karena waktu tunggu ditentukan rantai panggilan terpanjang. Peluang error atau halaman setengah kosong naik, karena makin banyak panggilan makin besar peluang salah satunya gagal atau timeout.
- Mitigasi (tambahan): API yang lebih coarse-grained (satu panggilan mengambil data sekaligus), caching, komunikasi asynchronous untuk bagian yang tidak perlu langsung, dan design for failure (halaman tetap tampil walau rekomendasi gagal).
Rujukan: 2.9.
C5. Request diproses 30 detik tanpa timeout
Soal. Sebuah request diproses lama (30 detik). Agar klien tidak timeout, jelaskan design pattern yang cocok.
Jawaban (berbasis konsep komunikasi asynchronous di 2.9):
- Klien mengirim request. Service tidak memproses sambil menahan koneksi; ia langsung membalas “diterima” beserta ID pekerjaan (mis. HTTP 202, tambahan).
- Pekerjaan diproses di belakang layar (mis. dimasukkan ke message queue lalu dikerjakan worker).
- Klien mendapat hasil dengan salah satu cara:
- Polling: klien berkala menanyakan status dengan ID tadi sampai hasilnya siap.
- Callback/notifikasi: klien memberi alamat callback, dan service memanggil balik saat selesai (atau memancarkan event yang di-subscribe klien).
Alasan: koneksi tidak ditahan selama 30 detik sehingga tidak timeout, resource klien dan server bebas, dan klien bisa mengerjakan hal lain (asynchronous non-blocking).
Sebagai rujukan, nama pattern-nya ada di materi design pattern (note 6, bukan cakupan UTS tahun ini): Service Callback, dan Request/Response varian Asynchronous atau Polling.
C6. Service validasi KTP dan nomor telepon untuk banyak aplikasi
Soal. Perusahaan ingin membuat service validasi KTP, nomor telepon, dan sejenisnya. Service dipakai 2 aplikasi, dan ke depan kemungkinan makin banyak. Jelaskan design pattern SOA yang cocok.
Jawaban (berbasis taksonomi dan prinsip di 2.5 dan 2.8):
- Jadikan validasi sebagai service agnostic yang berdiri sendiri, bukan kode yang disalin ke tiap aplikasi. Validasi tidak terikat satu proses bisnis, jadi dalam taksonomi termasuk utility service (agnostic), dan dipakai banyak aplikasi seperti Customer Lookup pada contoh cost-efficiency.
- Prinsip yang diterapkan:
- Reusable: didesain untuk aplikasi yang belum ada.
- Standardized contract: semua aplikasi memakai kontrak yang sama.
- Loose coupling dan abstraction: aplikasi tidak tahu sumber data validasinya.
- Stateless: mudah di-scale saat pemakai bertambah.
- Discoverable: didaftarkan di registry agar aplikasi baru menemukannya.
Sebagai rujukan, nama pattern-nya ada di note 6 (bukan cakupan UTS tahun ini): Agnostic Service, dan Agnostic Service Declaration (service menyatakan secara eksplisit bahwa ia didesain untuk dipakai ulang). Jika tiap aplikasi butuh bentuk kontrak berbeda, Service Façade bisa dipakai.
4. Soal Prediksi dan Jawaban
Disusun dari topik yang masuk cakupan tetapi belum pernah ditanyakan, dengan gaya soal yang sama: sebutkan dan jelaskan, bandingkan, kapan dipakai, beri contoh, atau terapkan ke kasus.
P1. SOA triangle
Soal. Jelaskan tiga entitas pada SOA triangle beserta operasi antar entitas, dan kaitkan dengan standar web service.
Jawaban.
- Service Provider membuat service dan publish deskripsinya ke Discovery Agency (registry).
- Discovery Agency menyimpan deskripsi service, misalnya UDDI.
- Service Requestor find: mencari service lewat Discovery Agency.
Setelah ketemu, requestor dan provider interact (bind dan invoke) secara langsung. Dalam web service: deskripsinya WSDL, registrinya UDDI, pesannya SOAP.
Rujukan: 2.2, 2.6.
P2. Service = Contract + Terms + QoS
Soal. Jelaskan komponen contract, terms, dan QoS pada sebuah service, dengan contoh payment service.
Jawaban.
- Contract: apa yang dilakukan service. Contoh: “menerima ID order dan nominal, mengembalikan status pembayaran”.
- Terms: properti service. Contoh: transaksi bersifat atomic (berhasil semua atau batal semua), terisolasi, dilindungi keamanannya, dan ada aturan bila gagal (dana dikembalikan).
- QoS: kondisi penyampaian layanan. Contoh: respons maksimal 5 detik, downtime setahun maksimal 5%.
Rujukan: 2.2.
P3. Klasifikasi task, entity, dan utility service
Soal. Pada sistem pemesanan tiket bioskop online, identifikasi minimal satu task service, dua entity service, dan dua utility service. Jelaskan alasannya.
Jawaban.
- Task: Pemesanan Tiket. Bersifat non-agnostic, khusus satu proses, dan mengomposisi service lain (cek kursi, bayar, terbitkan tiket).
- Entity: Film/Jadwal dan Pelanggan. Terkait entitas bisnis, agnostic, dan bisa dipakai proses lain (mis. promo, laporan).
- Utility: Notifikasi (email/SMS e-tiket) dan Logging/Security. Fungsi teknis yang tidak berasal dari analisis bisnis dan dipakai banyak service.
Rujukan: 2.5.
P4. Manfaat SOA dan “if managed well”
Soal. Sebutkan empat manfaat SOA dengan contoh, lalu jelaskan maksud “the hard part is the ‘if managed well’“.
Jawaban.
- Cost-efficiency: satu Customer Lookup dipakai banyak aplikasi.
- Agility: aplikasi baru (Course Management) dibangun cepat dari service yang sudah ada.
- Adaptability: perubahan Credit Check tidak berdampak ke aplikasi pemakainya karena komunikasinya standar.
- Leverage legacy: service membungkus sistem lama sehingga keragaman platform lama tersembunyi.
“If managed well” berarti manfaat itu tidak otomatis. Tanpa governance (siapa pemilik service, bagaimana versinya berubah, SLA, dan penyelesaian konflik), service bisa terduplikasi, tidak terpakai, atau saling merusak saat berubah.
Rujukan: 2.4, 2.11 (mitos 5).
P5. Mitos “sistem legacy mudah diintegrasikan”
Soal. Mengapa anggapan bahwa sistem legacy mudah diintegrasikan ke SOA adalah mitos? Apa yang harus dianalisis?
Jawaban. Membuka legacy sebagai service (wrapped service) butuh analisis awal:
- Kelayakan teknis membuat service dari sistem itu.
- Biaya membukanya sebagai service.
- Apakah biaya itu ditambah pemeliharaan lebih mahal daripada mengganti sistemnya.
- Perubahan apa yang dibutuhkan pada sistem lama.
- Dampak ke pengguna dan sistem produksi lain yang bergantung padanya.
Jadi integrasi legacy adalah keputusan bisnis dan teknis, bukan sekadar menambah pembungkus.
Rujukan: 2.4 (wrapped service), 2.11 (mitos 2).
P6. Mitos “SOA hanya soal teknologi” dan “standar saja cukup”
Soal. Jelaskan mengapa SOA bukan hanya soal teknologi atau standar.
Jawaban.
- Bukan hanya teknologi: SOA mengubah model governance: definisi service, repositori, kepemilikan service dan data bersama, evolusi versi, penyelesaian konflik, mekanisme deployment dan monitoring, kebijakan enterprise, dan SLA.
- Bukan hanya standar: standar dasar (XML, SOAP, WSDL) memang stabil, tetapi standar tingkat tinggi belum matang dan banyak yang tumpang tindih (mis. SAML vs WS-Security). Mitos ini lahir dari anggapan SOA = Web Services.
Kunci keberhasilan SOA adalah governance, yang hampir tidak berhubungan dengan teknologi.
Rujukan: 2.11 (mitos 3 dan 5).
P7. Mitos “pengujian tidak berbeda”
Soal. Mengapa pengujian sistem berbasis service berbeda dari pengujian aplikasi biasa?
Jawaban.
- Sistemnya terdistribusi.
- Service eksternal tidak bisa dikendalikan: ia black box, bisa hilang (“what if the service disappears?”), dan QoS-nya berubah menurut beban. Karena itu dibutuhkan exception management.
- Developer harus mengantisipasi pola pemakaian oleh consumer yang belum diketahui.
Rujukan: 2.11 (mitos 8).
P8. Discovery dan composition statis vs dinamis
Soal. Bedakan service discovery dan composition statis dan dinamis. Mengapa komposisi dinamis saat runtime masih dianggap mitos?
Jawaban.
- Statis (design time): developer mencari service, mendapat alamat, dan menulis kode pemanggilnya. Ini yang dipakai saat ini.
- Dinamis (runtime): aplikasi sendiri menemukan service, mendapat alamat, dan tahu data apa yang harus dikirim.
- Ada pendekatan in-between: aplikasi menemukan service, tetapi user ikut memilih.
Komposisi dinamis sulit karena butuh ontologi bersama dan aplikasi yang sangat cerdas: bisa membuat query discovery yang tepat, mengomposisi bila tidak ada satu service yang cukup, dan menyiapkan data yang benar untuk service yang baru ditemukan. Teknologinya belum matang untuk produksi.
Rujukan: 2.4, 2.11 (mitos 7).
P9. SOAP vs REST
Soal. Bandingkan SOAP dan REST dalam pembangunan web service. Kapan memilih masing-masing?
Jawaban.
| SOAP | REST | |
|---|---|---|
| Format | Pesan XML dalam envelope (header opsional, body wajib); pesan satu arah | Resource diakses lewat URI dan metode HTTP; representasi biasanya JSON (tambahan) |
| Kontrak | WSDL formal; bisa didaftarkan di UDDI | Kontrak lebih ringan (tambahan: OpenAPI) |
| Ekosistem | Standar WS-* (policy, security, BPEL) | Ringan, simple, dan stateless; gaya umum di microservice (HTTP resource API) |
| Cocok untuk | Integrasi enterprise yang butuh kontrak ketat dan kebijakan formal | Aplikasi web dan mobile, microservice, API publik yang sederhana |
Rujukan: 2.6, 2.9. Topik ini disebut slide W01b sebagai bahan diskusi “Myth Busting”.
P10. SOA klasik vs microservice
Soal. Bandingkan SOA klasik (dengan ESB dan orchestration) dengan microservice dari sisi lokasi logika integrasi, data, dan deployment.
Jawaban.
- Logika integrasi: SOA klasik menaruh banyak logika di ESB/service bus (smart pipe: transformasi, routing) dan orchestrator BPEL. Microservice memakai smart endpoints, dumb pipes: logika di service, komunikasinya sederhana (HTTP/REST, message queue), dan orchestration terpusat tidak disukai.
- Data: SOA klasik sering memakai data bersama atau sistem enterprise. Microservice memakai database per service.
- Deployment: microservice di-deploy terpisah per service dengan CI/CD dan sering memakai container.
- Persamaan: keduanya berorientasi service dan memakai prinsip yang sama (kontrak, loose coupling, reuse).
Rujukan: 2.5, 2.7, 2.9.
P11. Synchronous vs asynchronous pada microservice
Soal. Jelaskan komunikasi synchronous blocking dan asynchronous non-blocking (request-response dan event-driven) pada microservice. Berikan contoh kapan dipakai.
Jawaban.
- Synchronous blocking: pemanggil menunggu response (HTTP request-response). Sederhana, tetapi bisa membentuk rantai panjang. Contoh: cek saldo sebelum transfer.
- Asynchronous request-response: pemanggil meminta sesuatu, lanjut bekerja, dan menerima hasilnya belakangan. Contoh: pembuatan laporan besar.
- Asynchronous event-driven: service memancarkan event, dan service lain subscribe lalu bereaksi. Contoh: setelah order dibuat, inventory dan notifikasi bereaksi.
Asynchronous cocok untuk proses kompleks yang tidak butuh jawaban cepat. Karena kegagalan pasti terjadi, aplikasi microservice harus design for failure.
Rujukan: 2.9.
P12. Delivery lifecycle top-down vs bottom-up
Soal. Bandingkan pendekatan top-down dan bottom-up pada SOA delivery lifecycle, termasuk cara menemukan kandidat service.
Jawaban.
- Top-down (mulai dari nol): define ontology, align business models, service-oriented analysis, service-oriented design, develop, test, deploy. Hasilnya service yang selaras dengan bisnis, tetapi butuh waktu dan analisis di awal.
- Bottom-up (dari aplikasi yang ada): model, design, develop, test, dan deploy application services. Lebih cepat, tetapi service cenderung mengikuti aplikasi lama.
- Kandidat service: pendekatan task-centric (dari model proses bisnis/BPM: Invoice Submission, Order Fulfillment) atau entity-centric (dari entitas: Vendor Profile, Purchase Order).
Rujukan: 2.8.
P13. Memilih SaaS, PaaS, atau IaaS
Soal. Sebuah startup edu-tech dengan dua developer ingin meluncurkan aplikasi cepat, sedangkan tim riset kampus butuh OS dan software khusus. Model cloud apa yang cocok untuk masing-masing? Jelaskan trade-off-nya.
Jawaban.
- Startup: PaaS. Fokus menulis aplikasi tanpa mengurus server; platform menangani scaling dan availability. Trade-off: kurang fleksibel (AppEngine paling tidak fleksibel dan proprietary) dan ada risiko lock-in.
- Tim riset: IaaS. Bebas memilih OS dan seluruh software stack, mengelola dari kernel ke atas. Trade-off: tanggung jawab pengelolaan paling besar.
- SaaS dipakai untuk kebutuhan umum (mis. Dropbox, Salesforce) tanpa mengembangkan apa pun, tetapi hampir tidak fleksibel.
Pola umumnya: makin ke IaaS, makin fleksibel dan makin besar tanggung jawab pengguna.
Rujukan: 2.10.
P14. Over- dan under-provisioning
Soal. Sistem akademik kampus sangat sibuk pada dua minggu awal semester (drop/add). Jelaskan masalah over-provisioning dan under-provisioning pada on-premise, dan bagaimana cloud mengatasinya.
Jawaban.
- Over-provisioning: server dibeli untuk beban puncak, sehingga di luar masa drop/add sebagian besar kapasitas menganggur (utilisasi rata-rata server hanya 5–20%).
- Under-provisioning: server dibeli untuk beban rata-rata, sehingga saat drop/add request tidak terlayani dan mahasiswa kecewa atau pergi.
Cloud menawarkan elastisitas: kapasitas ditambah saat drop/add dan dikurangi sesudahnya, dibayar sesuai pemakaian, tanpa komitmen di muka. Catatannya, aplikasi harus bisa di-scale dan scale cepat tetap tantangan.
Rujukan: 2.10.
P15. Hambatan cloud dan mitigasinya
Soal. Pilih tiga hambatan adopsi cloud dan jelaskan cara mengatasinya.
Jawaban.
- Data lock-in: penyimpanan cloud cenderung proprietary. Mitigasi: API data terstandar, dan menurut kuliah tamu, vendor-agnostic dengan stack open source (Kubernetes, Ceph/MinIO, Prometheus).
- Business continuity dan availability: provider bisa mati. Mitigasi: lebih dari satu provider atau region, dan disaster recovery dengan RTO/RPO yang jelas.
- Data confidentiality dan auditability: data sensitif dan regulasi. Mitigasi: enkripsi, IAM dan rotasi API key, firewall/WAF, audit.
Alternatif: data transfer bottleneck (kirim disk fisik, CDN, peering), performance unpredictability, reputation fate sharing.
Rujukan: 2.10, 2.12.
P16. CapEx, OpEx, dan TCO
Soal. Jelaskan CapEx, OpEx, dan TCO dalam membangun layanan cloud sendiri. Mengapa engineer harus cost-aware?
Jawaban.
- CapEx: belanja sekali di awal (server, switch, router, rack).
- OpEx: biaya rutin bulanan (listrik, transit bandwidth, colocation, cooling, maintenance).
- TCO: biaya total kepemilikan. Rumus di slide:
TCO = CapEx + OpEx − Depresiasi, atau per bulan(CapEx ÷ umur server) + OpEx bulanan. Satuan waktunya harus disamakan.
Engineer harus cost-aware karena “cloud bukan magic, cloud adalah resource abstraction”: tagihan bisa melebihi profit. Kesalahan fatal yang disebut di kuliah: tidak menghitung bandwidth, tidak mengukur overhead VM idle, overprovision RAM, dan tidak memakai virtualization grouping.
Rujukan: 2.12.
P17. Membaca hasil load test
Soal. Hasil load test menunjukkan CPU flatline di 100%, RAM plateau, dan latensi di atas 500 ms. Apa artinya dan apa keputusanmu?
Jawaban.
- CPU flatline berarti CPU jenuh. Keputusan: tambah core atau pecah service.
- RAM plateau berarti ada memory leak atau oversubscribe. Keputusan: optimasi aplikasi atau tambah swap.
- Latensi > 500 ms berarti ada bottleneck. Keputusan: caching, lalu cari penyebabnya.
Jika IOPS yang jenuh, pakai NVMe atau perbaiki index database. Jika bandwidth yang jenuh, pakai CDN atau peering. Bottleneck paling umum adalah RAM habis.
Rujukan: 2.12.
P18. SLA bukan sekadar uptime
Soal. Mengapa SLA bukan sekadar angka uptime? Sebutkan komponennya, dan hitung downtime maksimum sebulan untuk SLA 99,9%.
Jawaban.
- Komponen SLA: maximum downtime per month, response time under load, backup retention, incident handling, compensation policy.
- Hitungan (30 hari = 43.200 menit): 99,9% berarti downtime maksimal sekitar 43 menit per bulan. Sebagai pembanding, 99,5% berarti sekitar 216 menit.
- Makin tinggi SLA, makin mahal harganya karena butuh redundansi (minimal 2 node/HA).
Rujukan: 2.12 dan tabel prasyarat di UTS_KomLay.
P19. Vertical vs horizontal scaling, dan RTO/RPO
Soal. Bandingkan vertical dan horizontal scaling. Jelaskan juga RTO, RPO, active-active, dan active-passive.
Jawaban.
- Vertical scale: menambah resource pada satu server. Sederhana, tetapi ada batasnya dan menjadi single point of failure.
- Horizontal scale: menambah banyak server kecil. Lebih murah jangka panjang dan lebih tahan gagal, tetapi aplikasinya harus siap didistribusikan (mis. stateless).
- RTO: berapa lama layanan boleh mati. RPO: berapa banyak data hilang yang masih bisa ditoleransi.
- Active-active: semua lokasi melayani sekaligus. Active-passive: lokasi cadangan siaga dan baru aktif saat lokasi utama gagal.
Rujukan: 2.12.
P20. Menjual layanan cloud sendiri
Soal. Kamu ingin menjual layanan cloud buatan sendiri ke UMKM. Pilih revenue model yang cocok, sebutkan elemen teknis yang wajib ada, dan parameter apa yang dijual.
Jawaban.
- Revenue model: shared hosting (cocok untuk UMKM, portfolio, proyek CSR), atau subscription SaaS bila produknya aplikasi.
- Elemen teknis wajib:
- multi-node atau opsi scalability;
- backup schedule dan retention policy;
- monitoring real-time dan logging terpusat;
- SLA target 99,5% atau 99,9%;
- security berupa rate limiting dan isolasi per tenant.
- Parameter yang dijual: CPU (vCore/slice), RAM per GB, storage (GB atau IOPS tier), bandwidth per TB, dan tingkat SLA.
- Kriteria komersial: harga logis, margin positif, market masuk akal, SLA jelas dan bisa dilaksanakan.
Rujukan: 2.12.
Catatan untuk P16–P20. Materi kuliah tamu (note 18–20) belum pernah muncul di soal lama. Bisa jadi materi ini lebih diarahkan ke proyek atau eksperimen daripada ujian, jadi prioritasnya di bawah topik inti. Pelajari konsepnya (CapEx/OpEx/TCO, bottleneck ke keputusan, komponen SLA), bukan hafalan harga.
5. Checklist Sebelum Ujian
- Bisa menulis definisi, 2 kelebihan, 2 kekurangan, dan kapan dipakai untuk orchestration dan choreography.
- Hafal 8 prinsip desain, dan untuk tiap prinsip punya satu contoh konkret.
- Bisa menjelaskan 3 karakter microservice beserta dampak dan kekurangannya.
- Bisa membedakan registry vs broker, syntactic vs semantic interoperability, dan fungsi WSDL.
- Bisa memecah satu studi kasus menjadi task, entity, dan utility service, lalu memetakannya ke microservice dengan database per service.
- Bisa menjelaskan sync vs async dan memberi solusi untuk request yang lama.
- Bisa menjelaskan keunggulan cloud beserta catatannya, dan memilih SaaS/PaaS/IaaS untuk sebuah kasus.