Mengenal dua spesifikasi WS-* untuk keandalan enterprise: WS-Addressing untuk menuju endpoint, action, dan pola reply asinkron, serta WS-ReliableMessaging untuk jaminan pengiriman pesan lewat sequence berikut peran idempotency dalam memproses ulang yang aman.

Setelah di episode 8 kita menangani error, sekarang kita naik kelas ke level keandalan enterprise. Envelope SOAP biasa hanya "kirim dan harap sampai" — di transport yang tidak stabil, pesan bisa hilang, duplikat, atau tiba di endpoint yang salah. Di sinilah WS-Addressing dan WS-ReliableMessaging masuk.
Mengapa penting? Dalam integrasi keuangan dan kesehatan, "pesan hilang" bukan masalah teknis — itu masalah hukum dan keuangan. Klaim yang tidak sampai bisa berarti layanan ditolak; transfer yang terkirim dua kali bisa berarti dana ganda. Dua spesifikasi ini adalah jawaban SOAP atas kebutuhan tersebut: memberi alamat yang benar (addressing) dan jaminan pengiriman (reliable messaging).
Transport HTTP hanya tahu "kirim ke URL ini". WS-Addressing membawa informasi alamat ke dalam pesan itu sendiri — sehingga pesan bisa di-routing melalui intermediary, dijawab ke endpoint lain, dan diidentifikasi secara unik.
Elemen inti WS-Addressing adalah Endpoint Reference (EPR):
<wsa:ReplyTo xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>http://client.internal/callback</wsa:Address>
<wsa:ReferenceParameters>
<tx:correlationId xmlns:tx="urn:example:tx">7f3a9c-2026</tx:correlationId>
</wsa:ReferenceParameters>
</wsa:ReplyTo>| Elemen | Fungsi |
|---|---|
wsa:To | Alamat tujuan akhir pesan |
wsa:Action | Identitas aksi/operasi (QName) |
wsa:ReplyTo | Tempat jawaban dikirim (pola asinkron) |
wsa:MessageID | Identitas unik pesan |
wsa:RelatesTo | Menghubungkan balasan ke pesan asli |
<soap:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:MessageID>urn:uuid:9a1c2b3d-20260816-001</wsa:MessageID>
<wsa:Action>urn:example:bank:getBalance</wsa:Action>
<wsa:To>http://localhost:8080/bank</wsa:To>
</soap:Header>wsa:Action sangat penting dalam SOAP 1.2: operasi diidentifikasi oleh nilai action, bukan hanya nama elemen di body. Salah action = operasi salah = request ditolak.
Kelebihan WS-Addressing adalah pola async: service bisa membalas ke wsa:ReplyTo yang berbeda dari endpoint asal. Ini memungkinkan long-running operation — kirim request, service memproses menit-menit, lalu mengirim jawaban ke callback. Tanpa WS-Addressing, pola ini mustahil karena HTTP response harus segera.
WS-ReliableMessaging (WS-RM) menjamin pesan sampai di tujuan dengan benar, meskipun transportnya tidak andal. Ia bekerja dengan membuka sequence dan memberi nomor urut pada setiap pesan.
Setiap pesan membawa nomor urut di header. Penerima mengakui nomor yang sudah diterima; pengirim mengirim ulang nomor yang hilang. Ini menjamin:
<soap:Header xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702">
<wsrm:Sequence>
<wsrm:Identifier>urn:uuid:seq-20260816-0001</wsrm:Identifier>
<wsrm:MessageNumber>7</wsrm:MessageNumber>
</wsrm:Sequence>
</soap:Header>Praktik ini umum dipakai di layanan yang memproses transaksi finansial antar-bank: koneksi bisa putus di tengah pengiriman, dan WS-RM memastikan urutan transaksi sampai lengkap.
WS-RM menjamin pengiriman, tetapi tidak menjamin hasil akhir bebas duplikat di sisi aplikasi. Pesan bisa diproses ulang (retry) oleh pengirim, dan receiver harus aman memprosesnya berulang kali. Di sinilah idempotency berperan.
Implementasi idempotency di level aplikasi:
wsa:MessageID (atau ID transaksi bisnis) dari pesan.def get_or_process(tx_id, fn):
existing = store.get(tx_id)
if existing:
return existing
result = fn()
store.set(tx_id, result)
return resultWarning
Jangan pernah mengandalkan WS-RM atau WS-Addressing saja untuk mencegah duplikasi transaksi finansial. Keduanya menjamin pengiriman, bukan deduplikasi hasil. Idempotency berbasis ID bisnis (mis. nomor klaim, nomor invoice) harus tetap diimplementasikan di aplikasi.
org.apache.cxf.ws.addressing.WSAddressingFeature dan WSReliableMessagingFeature.wsa:Action harus konsisten antara WSDL (wsaw:Action) dan pesan yang dikirim.Inti yang harus dibawa pulang:
To, Action, MessageID, ReplyTo.wsa:Action mengidentifikasi operasi; pola async dimungkinkan oleh ReplyTo.Di episode 10 selanjutnya kita akan membahas WS-Policy & service versioning — mendeklarasikan kebijakan keamanan dan transport di WSDL, namespace versioning, perubahan kompatibel, dan strategi deprecation untuk konsumen legacy. Sampai jumpa di episode 10!