6_SOA Design Patterns

Pattern vs Prinsip

Prinsip desain SOA (5_SOA Design Principles) adalah tujuan (apa yang ingin dicapai); SOA Design Patterns adalah solusi konkret berulang untuk mencapai prinsip tersebut dalam konteks masalah tertentu. Sumber: simplicable.com, SOA Design Patterns (Thomas Erl).

SOA Design Patterns (Erl) — mnemonic “AMSE”

Agnostic Service

• Masalah: logika yang common dibutuhkan berulang di banyak masalah bisnis berbeda.
• Solusi: service agnostic mengimplementasikan logika yang umum untuk berbagai masalah bisnis (bukan spesifik satu konteks). Memisahkan logika agnostic ke service diskrit memfasilitasi reuse dan composability.
• Prinsip terkait: reuse, service composability.

Agnostic Service Declaration

• Masalah: sulit membedakan mana service yang memang didesain untuk reuse (agnostic) dan mana yang tidak.
• Solusi: service agnostic harus secara eksplisit mendeklarasikan dirinya agnostic, agar jelas bagi desainer/pembangun berikutnya service mana yang didesain untuk dipakai ulang.
• Prinsip terkait: reuse, service composability.

Atomic Service Transaction

• Masalah: perubahan yang gagal di tengah proses bisa meninggalkan state yang tidak konsisten.
• Solusi: service dapat dibungkus dalam transaksi atomik dengan fitur rollback yang membalikkan semua aksi & perubahan. Transaction management service dapat diimplementasikan di layer komponen dan dipakai ulang banyak service.
• Prinsip terkait: service statelessness.

Enterprise Service Bus (ESB)

• Masalah: banyak service & consumer perlu saling terhubung tanpa membentuk point-to-point yang rumit.
• Solusi: ESB bertindak sebagai message broker antara consumer dan service. ESB dapat melakukan transformasi pesan, routing, dan terhubung ke aplikasi lewat berbagai protokol komunikasi.
• Prinsip terkait: loose coupling, interoperability, endpoint abstraction.

graph LR
  C1[Consumer] <--> ESB[[Enterprise Service Bus]]
  C2[Consumer] <--> ESB
  C3[Consumer] <--> ESB
  ESB <--> S1[Service]
  ESB <--> S2[Service]
  ESB <--> S3[Service]

Multi Service Contracts

• Masalah: satu service perlu mendukung banyak jenis consumer/kebutuhan berbeda tanpa memaksa semua consumer memakai kontrak yang sama.
• Solusi: satu service boleh mendukung beberapa kontrak sekaligus — untuk backward compatibility (saat service berubah, consumer lama tak perlu diperbarui) maupun memberi view berbeda untuk tujuan berbeda (memfasilitasi reuse).
• Prinsip terkait: reuse, loose coupling.

Service Façade

• Masalah: perubahan kontrak service memaksa perubahan pada service itu sendiri, menciptakan tight coupling.
• Solusi: service façade duduk di antara service dan kontraknya, menghilangkan tight coupling antara service dan kontrak. Tujuannya meminimalkan perubahan pada service jika kontrak berubah. Satu service bisa punya banyak façade untuk mendukung banyak kontrak.
• Prinsip terkait: loose coupling.

graph LR
  Consumer --> Contract[Kontrak/Contract] --> Facade[Service Façade] --> Service

Service Callback

• Masalah: consumer tidak boleh diblok menunggu service yang berjalan lama (long running).
• Solusi: service mengharuskan consumer-nya memanggil secara asynchronous. Jika consumer butuh response, ia menyediakan alamat callback; saat service mencapai suatu milestone pemrosesan, ia mengirim pesan ke consumer lewat callback tersebut. Membebaskan resource, berguna untuk service yang diperkirakan long running.
• Prinsip terkait: loose coupling.

Authentication Broker

• Masalah: tiap service harus mengautentikasi consumer sendiri-sendiri, memboroskan usaha & rawan inkonsistensi.
• Solusi: authentication broker mengambil alih tanggung jawab mengautentikasi consumer. Consumer diberi token yang bisa dipakai mengakses service-service.
• Prinsip terkait: service composability.

Message Origin Authentication

• Masalah: perlu memastikan pesan benar-benar berasal dari pengirim yang sah.
• Solusi: sertifikat digital dipakai untuk mengautentikasi klien; hanya pesan yang ditandatangani digital yang diterima.
• Prinsip terkait: service composability.

Message Screening

• Masalah: pesan berbahaya (mis. mengandung payload jahat) bisa masuk dan diproses service.
• Solusi: pesan disaring (screened) untuk data berbahaya sebelum diproses.
• Prinsip terkait: standardized service contract.

Message Exchange Patterns (MEP)

Klasifikasi pola pertukaran pesan antar service — dari yang sederhana (Simple MEPs) sampai kompleks (Complex MEPs):

Simple MEPs
├── One-Way
│   ├── Asynchronous
│   └── Asynchronous/Verifiable
├── Synchronous/Reliable
├── Physical
│   ├── Asynchronous
│   ├── Synchronous
│   ├── Blocking
│   └── Non-blocking
└── Request/Response
    ├── Synchronous
    ├── Asynchronous
    └── Polling
Complex MEPs
├── Publish/Subscribe
└── Request/Call-back

Request/Response

sequenceDiagram
  participant C as Consumer
  participant P as Provider
  Note over C,P: Synchronous Request/Response
  C->>P: Request
  P-->>C: Response

• Synchronous: consumer menunggu (blok) sampai provider mengirim response.
• Asynchronous: consumer mengirim request lalu lanjut memproses; response ditangkap lewat onMessage() saat tiba (dilakukan dalam loop pengecekan response == null).
• Polling: consumer mengirim request, lalu secara berkala memanggil checkForResponse() ke provider sampai response tersedia (bukan provider yang mendorong balik).

One-Way

sequenceDiagram
  participant C as Consumer
  participant P as Provider
  Note over C,P: Asynchronous/Verifiable One-Way
  C->>P: One-Way Message
  P-->>C: Acknowledgement
  C->>P: retryUnverified() → One-Way Message (jika belum ada ack)

• Asynchronous: consumer mengirim pesan satu arah tanpa menunggu balasan apa pun.
• Synchronous/Reliable: consumer mengirim pesan dan menunggu acknowledgement (bukan hasil bisnis, hanya konfirmasi diterima).
• Asynchronous/Verifiable: mirip reliable, tapi jika acknowledgement tidak kunjung diterima, consumer akan retry mengirim ulang pesan yang belum terverifikasi (retryUnverified).

Publish/Subscribe

sequenceDiagram
  participant A as Consumer A
  participant B as Consumer B
  participant C as Consumer C
  participant P as Provider
  A->>P: Subscribe to X
  B->>P: Subscribe to X
  C->>P: Post Message to X
  P-->>B: New Message on Topic X
  P-->>A: New Message on Topic X

Consumer men-subscribe ke topik tertentu; ketika ada consumer lain yang post pesan ke topik itu, provider mem-broadcast pesan tersebut ke semua subscriber topik itu.

Request/Call-back

sequenceDiagram
  participant C as Consumer
  participant P as Provider
  C->>P: Request (myFunction)
  P-->>C: myFunction()

Consumer mengirim request yang menyertakan referensi fungsi callback (myFunction); provider akan memanggil balik fungsi tersebut pada consumer ketika hasil siap — mirip prinsip di balik pattern Service Callback di atas.

Microservices Design Patterns (Taxonomy)

Referensi luas untuk pola desain microservice: microservices.io oleh Chris Richardson. Taksonomi ini mengelompokkan puluhan pattern ke dalam kategori besar: Application patterns (Decomposition, Data patterns, Testing, UI), Application Infrastructure patterns (Cross-cutting concerns, Security, Communication style, Reliability, Observability), dan Infrastructure patterns (Deployment, Discovery, Communication patterns, External API).

The Microservice Architecture Pattern Language (Chris Richardson) — peta pattern microservice dari arsitektur monolitik/microservice, decomposition, data patterns, sampai deployment & discovery. Beberapa pattern penting di dalamnya (Saga, CQRS, Circuit Breaker, Event Sourcing, API Gateway, Service Mesh, Sidecar) dibahas lebih lanjut di 9_Integration Patterns dan 13_SOA Performance, Scalability & Availability.

Flashcard

flashcards Sebutkan pattern SOA yang berfungsi sebagai message broker antara consumer & service, sekaligus melakukan transformasi & routing pesan :: Enterprise Service Bus (ESB) — prinsip terkait: loose coupling, interoperability, endpoint abstraction. Apa perbedaan Agnostic Service dan Agnostic Service Declaration? :: Agnostic Service = implementasi logika yang common untuk berbagai masalah bisnis. Agnostic Service Declaration = keharusan service agnostic mendeklarasikan dirinya secara eksplisit agar jelas mana yang didesain untuk reuse. Jelaskan pattern Service Façade dan tujuannya :: Façade diletakkan di antara service dan kontraknya untuk menghilangkan tight coupling; tujuannya meminimalkan perubahan pada service jika kontrak berubah, satu service bisa punya banyak façade. Jelaskan pattern Service Callback dan kapan berguna :: Consumer memanggil service secara asynchronous dan menyediakan alamat callback; saat service mencapai milestone, ia mengirim pesan balik ke consumer via callback — berguna untuk service yang long-running karena membebaskan resource. Apa perbedaan Authentication Broker dan Message Origin Authentication? :: Authentication Broker mengambil alih otentikasi consumer dan memberi token akses; Message Origin Authentication memakai sertifikat digital untuk memverifikasi pesan benar dari klien yang sah (hanya pesan bertanda tangan digital diterima). Apa perbedaan Synchronous, Asynchronous, dan Polling pada pattern Request/Response? :: Synchronous: consumer blok menunggu response. Asynchronous: consumer lanjut proses lain, response ditangkap via callback/onMessage saat tiba. Polling: consumer berkala mengecek (checkForResponse) ke provider sampai response tersedia. Apa perbedaan One-Way Asynchronous, Synchronous/Reliable, dan Asynchronous/Verifiable? :: Asynchronous: kirim pesan tanpa menunggu balasan apapun. Synchronous/Reliable: menunggu acknowledgement (bukan hasil bisnis). Asynchronous/Verifiable: mirip reliable tapi retry otomatis jika ack belum diterima. Bagaimana cara kerja pola Publish/Subscribe? :: Consumer subscribe ke suatu topik; ketika ada consumer lain yang post pesan ke topik tsb, provider mem-broadcast pesan tersebut ke semua subscriber topik itu. Apa itu Microservice Architecture Pattern Language dan siapa penulisnya? :: Taksonomi/peta besar pola desain microservice (dari decomposition, data pattern, communication, sampai deployment & discovery) oleh Chris Richardson di microservices.io.