Belajar SOAP - MTOM & Attachment

#Pendahuluan

Setelah di episode 10 kita mengelola kebijakan dan versi, sekarang kita tangani kasus khusus yang sering muncul di integrasi B2B: mengirim file biner — scan dokumen, PDF, gambar, tanda tangan digital. Di episode 7 kita menyebut bahwa base64 di dalam XML boros; episode ini membahas solusi resminya: MTOM.

Mengapa penting? Coba kirim scan KTP 2 MB sebagai base64: ukurannya membengkak ~33% menjadi ~2,7 MB, dan seluruhnya harus diparsing sebagai teks di memory. Untuk sistem yang mengirim ribuan dokumen sehari, ini membebani bandwidth dan CPU. MTOM menyelesaikannya dengan memindahkan byte biner keluar dari XML — tanpa mengubah kontrak SOAP.

#Masalah Base64 di Dalam XML

Base64 mengubah data biner menjadi teks yang aman untuk XML. Konsekuensinya:

1. Ukuran bertambah ~33% — setiap 3 byte jadi 4 karakter ASCII.
2. Seluruh isi di-parse sebagai teks — 2 MB file jadi 2,7 MB string yang harus diproses XML parser.
3. Memori membengkak — API Java String memakai 2 byte/char di memory; string base64 2,7 MB berarti ~5,4 MB memory, berlipat untuk file yang lebih besar.

Untuk dokumen kecil (logo, KTP), base64 di dalam XML masih bisa ditoleransi. Untuk file besar atau throughput tinggi, ini tidak scalable.

#Cara Kerja MTOM/XOP

MTOM (Message Transmission Optimization Mechanism) memakai XOP (XML-binary Optimized Packaging): byte biner dikeluarkan dari dokumen XML dan dikirim sebagai attachment dalam pesan MIME multipart, sementara XML hanya menyimpan placeholder yang menunjuk ke attachment-nya.

HTTP/1.1 200 OK
Content-Type: multipart/related; boundary=soap-mtom;
  type="application/xop+xml"
 
--soap-mtom
Content-Type: application/xop+xml; type="text/xml"
 
<?xml version="1.0"?>
<soap:Envelope ...>
  <soap:Body>
    <uploadDocument>
      <fileName>ktp.pdf</fileName>
      <content>
        <xop:Include href="cid:ktp-2026"
          xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
      </content>
    </uploadDocument>
  </soap:Body>
</soap:Envelope>
 
--soap-mtom
Content-Type: application/pdf
Content-ID: <ktp-2026>
Content-Transfer-Encoding: binary
 
%PDF-1.4 ... (byte mentah PDF) ...
--soap-mtom--

Elemen <xop:Include href="cid:ktp-2026"/> adalah placeholder. Parser XOP menggantikannya dengan byte dari part yang Content-ID-nya cocok. Kontrak SOAP tidak berubah — di level semantik, content tetap elemen base64Binary; hanya representasi fisiknya yang dioptimasi.

#MTOM di Java: DataHandler

Java memakai DataHandler (dari JAXB/JavaBeans Activation Framework) sebagai tipe untuk data biner yang dioptimasi. Saat JAX-WS mendeteksi DataHandler, ia otomatis memakai MTOM bila fiturnya diaktifkan:

JAXB class dengan DataHandler

import jakarta.activation.DataHandler;
import jakarta.xml.bind.annotation.XmlElement;
import jakarta.xml.bind.annotation.XmlMimeType;
 
public class DocumentPayload {
    @XmlElement
    private String fileName;
 
    @XmlElement
    @XmlMimeType("application/octet-stream")
    private DataHandler content;
}

Aktifkan MTOM di service:

Aktifkan MTOM di JAX-WS

import jakarta.xml.ws.soap.SOAPBinding;
 
SOAPBinding binding = (SOAPBinding) endpoint.getBinding();
binding.setMTOMEnabled(true);

Setelah itu, upload dokumen cukup dengan DataHandler:

Service upload

@WebMethod
public void uploadDocument(DocumentPayload doc) {
    DataHandler handler = doc.getContent();
    InputStream in = handler.getInputStream();
    // simpan ke penyimpanan file/objek storage
}

getInputStream() membaca byte dari part MIME tanpa pernah memuat seluruhnya sebagai string — itulah keuntungan memory utama MTOM.

#MTOM di Bahasa Lain

#MTOM vs SOAP with Attachments (SwA)

Sebelum MTOM, ada SwA (SOAP with Attachments, 2000) — attachment MIME yang tidak diwakili placeholder XOP. Perbandingannya:

Untuk integrasi baru, selalu pilih MTOM. SwA hanya relevan untuk memahami service legacy yang masih hidup di beberapa sektor.

#Common Pitfalls

• MTOM menyala tanpa DataHandler — kalau tipe biner memakai byte[], JAX-WS tetap mengirim base64 di XML; MTOM hanya otomatis untuk DataHandler.
• Batasi ukuran payload di server — MTOM memindahkan byte keluar XML, tetapi upload tetap bisa menghabiskan memory/disk jika tidak dibatasi (detail di episode 12).
• Hitung checksum — file yang melintasi banyak proxy berisiko korup; sertakan checksum (SHA-256) di elemen payload dan verifikasi di sisi penerima.
• Konten-sensitif — file medis/hukum sering wajib dienkripsi level pesan (WS-Security, episode 14-15); MTOM hanya mengoptimasi transport, bukan keamanan.

#Penutup

Inti yang harus dibawa pulang:

• Base64 di dalam XML boros: +33% ukuran dan diproses sebagai teks di memory.
• MTOM/XOP memindahkan byte biner keluar XML jadi attachment MIME, dengan placeholder <xop:Include>.
• Kontrak WSDL tidak berubah — base64Binary tetap, optimasi transparan.
• Java memakai DataHandler + setMTOMEnabled(true).
• Prefer MTOM atas SwA; pastikan fallback base64 untuk stack yang tidak mendukung MTOM.

Di episode 12 selanjutnya kita akan membahas performance: caching, pooling & timeout — tuning client HTTP (connection pooling, timeout, retry, caching response) dan tuning server (thread pool, batas ukuran payload, monitoring service). Sampai jumpa di episode 12!