Empat pendekatan utama integrasi dalam SOA yang dibahas di sini: Enterprise Service Bus, API Gateway, Service Mesh, Event Streaming. Semuanya dipraktikkan lewat studi kasus yang sama — sistem kesehatan yang menghubungkan dua rumah sakit (Pine Valley Hospital & Grand Oak Hospital) dengan API pengecekan ketersediaan dokter yang berbeda-beda formatnya, di-front oleh satu Doctor Booking Service.
Enterprise Service Bus (ESB)
Nama ESB adalah analogi bus perangkat keras pada motherboard yang menghubungkan semua komponen. ESB adalah middleware tempat service SOA di-deploy dan dipublikasikan agar bisa dikonsumsi sistem lain — mengubah topologi “spaghetti dish” (point-to-point kacau) menjadi topologi rapi dengan satu bus di tengah.
API Gateway
- Menyediakan satu titik masuk API yang terunifikasi untuk satu atau lebih API internal.
- Proxy multifaset yang melakukan integrasi, intermediasi, dan pengayaan (enrichment).
- Punya seluruh informasi endpoint microservice untuk melakukan mediasi, routing, dan invoke endpoint yang tepat — dilakukan setelah verifikasi request awal, content filtering, autentikasi, dan otorisasi.
- Fitur umum: authentication & authorization, message enrichment, remediation, process-based composition, traffic routing & management, service monitoring.
WSO2 Integrator (contoh tool)
WSO2 Enterprise Integrator dapat berperan sebagai API Gateway sekaligus ESB, dengan Integrator Studio sebagai GUI-nya, mendukung Service Integration, Data Integration, Business Processes, Messaging, Analytics, Tooling.
Skenario Integrasi — Studi Kasus Doctor Booking
Skenario I: Orchestration Middleware
- Middleware (mis. WSO2 Micro Integrator) mengorkestrasi request dari user, menyatukan hasil dari dua API rumah sakit menjadi satu response.
- Pendekatan ini mirip pendekatan orkestrasi BPMN memakai orchestration engine seperti Camunda (lihat 3_BPM dan BPMN).
sequenceDiagram participant U as User participant HA as Healthcare API (Micro Integrator) participant PV as Pine Valley Hospital participant GO as Grand Oak Hospital U->>HA: HTTP GET HA->>PV: HTTP POST PV-->>HA: JSON HA->>GO: HTTP GET GO-->>HA: JSON HA-->>U: JSON (gabungan)
Skenario II: API Gateway
- Fungsionalitas sama seperti Skenario I, tapi memakai strategi integrasi berbeda: API Gateway (mis. Kong) langsung menghubungi service via rest connector, tanpa lapisan orkestrasi eksplisit di tengah.
- Masalah yang muncul: kedua rumah sakit punya format API berbeda — Grand Oak menerima
GETdi/grandOak/doctors/<DOCTOR_TYPE>, sedangkan Pine Valley menerimaPOSTdi/pineValley/doctorsdengan payload JSON{"doctorType": "..."}. Perbedaan ini tetap perlu ditangani baik di API Gateway maupun orchestrator.
Skenario III: Service Mesh
Komunikasi antar service diatur lewat proxy yang disebut sidecar — tiap service (Doctor Booking Service, Pine Valley Hospital Service, Grand Oak Hospital Service) punya sidecar proxy-nya sendiri yang saling berkomunikasi.
graph LR subgraph "Pine Valley" PVS[Pine Valley Service] --- PVP[Sidecar Proxy] end subgraph "Doctor Booking" DBS[Doctor Booking Service] --- DBP[Sidecar Proxy] end subgraph "Grand Oak" GOS[Grand Oak Service] --- GOP[Sidecar Proxy] end PVP <--> DBP DBP <--> GOP
Sidecar Pattern:
- Masalah: aplikasi/service sering butuh fungsi terkait tapi terpisah (monitoring, logging, konfigurasi, jaringan). Jika diintegrasikan ketat ke aplikasi: efisien tapi tidak terisolasi & bergantung ke aplikasi induk. Jika jadi service terpisah: independen & fleksibel, tapi menambah latensi & kompleksitas.
- Solusi: menempatkan (co-locate) sekumpulan task terkait bersama aplikasi utama, tapi dalam proses/container terpisah, menyediakan interface seragam untuk platform services lintas bahasa.
Arsitektur Service Mesh secara umum: Control Plane (mengatur konfigurasi lewat CLI/API) mengontrol Data Plane — kumpulan instance aplikasi, masing-masing dengan sidecar proxy yang saling terhubung (East-West traffic) dan melapor ke sistem Observe & Trace.
Skenario IV: Event Streaming
API Gateway menghubungi sistem Kafka di backend; strategi integrasinya asynchronous & tidak langsung lewat event-based system (message queue).
graph LR U[User] -->|HTTP GET| GW[API Gateway] GW --> K[(Kafka)] K -->|rest connector| PV[Pine Valley Hospital] K -->|rest connector| GO[Grand Oak Hospital]
Event Streaming dengan Kafka
Event Streaming mencakup:
- Menangkap data real-time dari sumber (database, sensor, mobile device, cloud service, aplikasi) sebagai stream event.
- Menyimpan event stream secara durable untuk diambil kemudian.
- Memanipulasi, memproses, dan menanggapi event stream secara real-time maupun retrospektif.
- Mengarahkan event stream ke berbagai destinasi sesuai kebutuhan.
Use case: transaksi keuangan real-time (bursa saham, bank), pelacakan logistik/kendaraan real-time, analisis sensor IoT, reaksi cepat terhadap interaksi/order pelanggan, monitoring pasien rumah sakit, fondasi data platform/event-driven architecture/microservices.
Apa itu Kafka?
- Mirip sistem messaging (publish/subscribe) seperti ActiveMQ, RabbitMQ, MQSeries — tapi berbeda secara fundamental:
- Bekerja sebagai sistem terdistribusi modern: berjalan sebagai cluster, bisa scale menangani aplikasi skala sangat besar.
- True storage system — data disimpan untuk selama yang diinginkan (bukan sekadar antrian sementara); replikasi & persistensi memberi jaminan pengiriman nyata.
- Kapabilitas stream processing memungkinkan komputasi derived streams/datasets secara dinamis dengan lebih sedikit kode.
Arsitektur Kafka
- Server: dikelompokkan dalam cluster yang bisa mencakup banyak datacenter/cloud region; highly available & fault tolerant.
- Client: baca, tulis, dan proses stream event secara paralel.
- Event: punya key, value, timestamp, dan metadata header opsional (contoh: key=
"Alice", value="Made a payment of $200 to Bob", timestamp=waktu kejadian). - Producer — client yang publish (menulis) event ke Kafka.
- Consumer — client yang subscribe (membaca & memproses) event.
- Topic — koleksi event yang terurut dan disimpan secara durable, seperti folder berisi file; bisa kecil/besar, short-lived/long-lived; multi-producer & multi-subscriber. Berbeda dari queue lain, event tidak otomatis dihapus setelah dikonsumsi — retensi diatur lewat konfigurasi topik.
- Serialisasi: Avro, JSON, atau teks.
Contoh topik: truck_gps — tiap truk mengirim posisi GPS tiap 20 detik ke Kafka; topik ini bisa dikonsumsi banyak konsumen sekaligus (mis. Location Dashboard dan Notification Service); topik bisa dikonfigurasi dengan beberapa partition (mis. 10 partisi).
ESB vs Event Streaming
| ESB | Event Streaming | |
|---|---|---|
| Filosofi | ”Smart Pipes, Dumb Ends” — middleware pintar, endpoint sederhana | ”Smart Ends, Dumb Pipes” — endpoint pintar, middleware sederhana |
Other Queues (Perbandingan Message Queue)
| Queue | Protokol | Sinkron/Async | Catatan |
|---|---|---|---|
| Kafka | Binary over TCP | Asynchronous | Open source, banyak dipakai perusahaan skala besar (LinkedIn, Spotify, Uber) |
| RabbitMQ / ActiveMQ | AMQP | Mendukung keduanya | Open source |
| Google Pub/Sub | HTTP, gRPC | Asynchronous | Cloud-managed |
| AWS SQS | HTTP dsb. | Mendukung keduanya | Hanya mendukung 1:1 (bukan pub/sub); tidak menjamin “queue” sampai iterasi terakhir |
| Amazon SNS | HTTP, HTTPS, SMTP, SMS, dsb. | Asynchronous | Mendukung pub/sub |
Sidecar Pattern (ringkasan)
Lihat penjelasan lengkap di bagian Skenario III di atas — pattern ini juga relevan sebagai bagian dari taksonomi pattern microservice deployment (lihat 6_SOA Design Patterns).
Flashcard
flashcards Sebutkan 4 pendekatan integrasi SOA yang dibahas beserta studi kasusnya :: Enterprise Service Bus (ESB), API Gateway, Service Mesh, Event Streaming — semua dipraktikkan lewat studi kasus Doctor Booking Service yang menyatukan API dua rumah sakit (Pine Valley & Grand Oak). Apa perbedaan Skenario I (Orchestration Middleware) dan Skenario II (API Gateway)? :: Skenario I memakai middleware (mis. WSO2 Micro Integrator) yang mengorkestrasi & menyatukan hasil dari kedua API; Skenario II memakai API Gateway (mis. Kong) yang menghubungi service langsung via rest connector tanpa lapisan orkestrasi eksplisit. Jelaskan Sidecar Pattern: masalah dan solusinya :: Masalah: aplikasi butuh fungsi terkait (monitoring, logging, konfigurasi) tapi integrasi ketat tidak terisolasi sedangkan service terpisah menambah latensi. Solusi: co-locate task terkait bersama aplikasi utama tapi dalam proses/container terpisah, memberi interface seragam lintas bahasa. Apa komponen utama arsitektur Service Mesh? :: Control Plane (mengatur konfigurasi via CLI/API) mengontrol Data Plane (instance aplikasi dengan sidecar proxy masing-masing yang saling terhubung / East-West traffic), dilaporkan ke sistem Observe & Trace. Sebutkan 3 fungsi kunci Kafka sebagai event streaming platform :: (1) Publish dan subscribe stream event, (2) Store stream event secara durable & reliable selama yang diinginkan, (3) Process stream event secara real-time maupun retrospektif. Apa perbedaan Kafka dengan message broker konvensional (RabbitMQ dsb)? :: Kafka bekerja sebagai sistem terdistribusi modern yang bisa di-scale sebagai cluster, merupakan true storage system (data disimpan selama yang diinginkan, bukan sekadar antrian sementara), dan punya kapabilitas stream processing. Apa itu Topic dalam Kafka dan bagaimana sifat retensi event-nya? :: Koleksi event yang terurut, disimpan durable seperti folder, bersifat multi-producer & multi-subscriber; event TIDAK otomatis dihapus setelah dikonsumsi (beda dari queue tradisional), retensi diatur lewat konfigurasi. Apa perbedaan filosofi ESB dan Event Streaming? :: ESB = “smart pipes, dumb ends” (middleware pintar, endpoint sederhana); Event Streaming = “smart ends, dumb pipes” (endpoint pintar, middleware sederhana). Apa keterbatasan utama AWS SQS dibanding Kafka/SNS? :: AWS SQS hanya mendukung pola 1:1 (bukan publish/subscribe) dan tidak menjamin sifat “queue” sampai iterasi terakhir produknya.