SOAP 連携は、最初から大げさな基盤として始まることはあまりありません。
たいていは、
とりあえず 1 本スクリプトを書けばいい
から始まります。
それで済むのは、最初のうちだけです。
どこで話が変わるのか
同じ SOAP 連携が、いつの間にか次にも使われ始めると空気が変わります。
- 別の夜間バッチ
- 社内の管理画面
- もう 1 つのバックエンドサービス
- ブラウザ向けのプロキシ
この時点で、最初の 1 本は単なるスクリプトではなくなります。
なぜスクリプトが太っていくのか
SOAP は、呼び出し側に契約の細かい事情を多く背負わせます。
- 認証方式
- envelope の組み立て
- namespace
- SOAPAction や binding の選択
- fault の扱い
つまり、そのスクリプトは業務ロジックだけではなく、小さな連携ランタイムでもあります。
見えない基盤になったサイン
だいたい次のような会話が出始めたら、もう単発ではありません。
- 「正しいリクエスト形はどれ？」
- 「バッチの認証処理を別のサービスでも使えない？」
- 「XML を手でいじらずに試せる場所はある？」
- 「staging と production で endpoint が違うのはどこで吸収する？」
この段階では、シェルスクリプトや補助モジュールの中に、説明されていない基盤ができ始めています。
何を 1 か所に寄せるべきか
同じ SOAP 依存が複数のリリースをまたいで残るなら、価値があるのは次を集約することです。
- 認証処理
- リクエストの整形
- WSDL からの契約把握
- fault の正規化
- テストとドキュメントの入口
ここまで来ると、管理された連携境界を 1 つ置いた方が自然です。
実務上の結論
単発スクリプトは、単発で終わるなら問題ありません。
でも、連携が残るなら、あるいは利用者が増えるなら、SOAP の細部をコピーしたスクリプト群のまま運用するのは、壊れやすい基盤を偶然育てるのとほとんど同じです。