Belajar SOAP - Modernisasi: SOAP→REST & Migrasi Strategis

#Pendahuluan

Setelah di episode 20 kita mengintegrasikan SOAP dengan gateway dan ESB, sekarang kita bahas tujuan akhir perjalanan banyak organisasi: migrasi dari SOAP ke REST — tetapi dengan cara yang aman dan bertahap.

Mengapa penting? Migrasi protokol itu seperti mengganti fondasi rumah yang masih dihuni. Mematikan SOAP langsung dan membangun REST baru adalah big-bang rewrite — kegagalan yang paling mahal dan paling umum dalam modernisasi. Episode ini mengajarkan pola industri yang terbukti: strangler pattern dan parallel run, yang memigrasikan sistem tanpa downtime dan tanpa memutus konsumen legacy.

#Mengapa Migrasi Gagal

Penyebab kegagalan migrasi SOAP→REST yang paling sering ditemui:

1. Big-bang rewrite — menulis ulang semua service sekaligus, lalu "switch total". Satu bug dan seluruh sistem down.
2. Mengabaikan konsumen legacy — mitra yang masih memakai SOAP diputus sebelum waktunya.
3. REST yang buruk — memigrasikan struktur SOAP "as is" ke REST tanpa desain resource yang benar: hasilnya "SOAP dengan JSON", bukan REST.
4. Tanpa translator — perbedaan format antara dua sistem dipaksa diselesaikan di kode konsumen.

#Strangler Pattern

Pola strangler memigrasikan per operasi, bukan per sistem. Setiap operasi lama digantikan satu per satu, sementara sistem berjalan normal:

Alurnya:

1. Tahap 1: semua konsumen masih memanggil SOAP.
2. Tahap 2: REST mulai dibangun per operasi; konsumen baru memakai REST; konsumen lama masih lewat translator ke SOAP.
3. Tahap 3: semua konsumen di REST; translator mengarah ke REST; SOAP dipensiunkan.

Kunci keberhasilan: satu operasi di-migrasi, diuji, dan dipotong — bukan semuanya sekaligus.

#Parallel Run

Sebelum memotong ke REST, jalankan keduanya berdampingan untuk operasi yang sama dan bandingkan hasilnya:

Request konsumen
  -> Dipanggilkan ke REST Service
  -> Dipanggilkan ke SOAP Service (untuk verifikasi)
  -> Hasil dibandingkan (diff)
  -> Selisih dianalisis sebelum REST dipercaya

Bekali sistem dengan comparison harness: kunci hasil SOAP dan REST pada request yang sama, lalu diff responsenya. Selama selisih masih muncul, jangan potong SOAP. Saat selisih nol dalam periode tertentu, potong.

#Memetakan WSDL ke OpenAPI

Migrasi menuntut kontrak baru: dari WSDL ke OpenAPI. Pemetaan per konsep:

Aturan desain yang sering dilanggar saat migrasi — jangan memindahkan operasi RPC "as is" menjadi URL unik per operasi (POST /getBalance, POST /transfer). Desainlah resource yang benar: akun, transfer, klaim. REST dihargai karena resource model-nya, bukan karena JSON-nya.

#Contoh pemetaan: WSDL → OpenAPI

<portType name="BankPortType">
  <operation name="getBalance">
    <input message="tns:GetBalanceRequest"/>
    <output message="tns:GetBalanceResponse"/>
  </operation>
</portType>

openapi: 3.0.0
paths:
  /accounts/{accountNo}/balance:
    get:
      operationId: getBalance
      parameters:
        - name: accountNo
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: Saldo akun
          content:
            application/json:
              schema:
                type: object
                properties:
                  balance:
                    type: string
                    format: decimal
        "404":
          description: Akun tidak ditemukan

#Translator Layer

Translator adalah lapisan yang menjembatani dua protokol selama masa transisi — di sinilah pola REST facade (episode 19-20) berubah menjadi alat migrasi:

Translator bisa berupa service mandiri, fungsi di gateway, atau filter di broker (Camel/WSO2). Yang penting: logika bisnis tidak boleh hidup di translator — ia hanya memetakan protokol, bukan memutuskan aturan bisnis.

#Roadmap Hybrid Tanpa Downtime

Roadmap lengkap yang menggabungkan semuanya:

#Penutup

Inti yang harus dibawa pulang:

• Hindari big-bang rewrite; pakai strangler pattern — migrasi per operasi.
• Parallel run dengan diff otomatis membuktikan REST siap dipotong tanpa tebakan.
• Petakan WSDL ke OpenAPI dengan desain resource yang benar, bukan RPC "as is".
• Translator layer menjembatani protokol selama transisi — tanpa logika bisnis di dalamnya.
• Roadmap bertahap + jadwal transisi untuk konsumen legacy = tanpa downtime dan tanpa memutus siapa pun.

Di episode 22, episode penutup series, kita akan membahas ekosistem tooling modern & refleksi akhir — Apache CXF 4.2.x dan WSS4J 4.0.1, Axis2, SoapUI, zeep, rekap Episode 0-21, checklist produksi, dan sumber resmi untuk terus belajar. Sampai jumpa di episode 22!