つらい連携案件の代表例がこれです。
- サービスは SOAP
- 所有者は委託先やパートナー
- でも納期の責任はこちらが負う
この組み合わせでは、納期の責任だけこちらにあり、仕様の主導権はありません。
なぜこの案件は長引きやすいのか
問題は SOAP そのものだけではありません。
改善要求を出しても、たいてい次のような返答になります。
- 「そのベンダーパッケージの仕様です」
- 「今は schema を変更できません」
- 「WSDL の定義通りに使ってください」
つまり、適応コストは全部こちらが飲み込む構造になりがちです。
やってはいけない形
一番まずいのは、下流の各チームがそれぞれ直接その SOAP に向き合うことです。
そうなると次が全部重複します。
- 認証処理
- WSDL 解釈
- XML 生成
- SOAP fault の扱い
本来は 1 つの連携課題だったものが、少しずつ別々の 5 つの課題に増えていきます。
管理された境界を置く意味
この種の案件では、SOAP-to-REST 層は「委託先の仕様に対して、こちら側で吸収する場所」として意味を持ちます。
1か所に寄せたいのは次です。
- 上流 SOAP の認証
- WSDL からのオペレーション把握
- JSON のリクエスト形式
- 下流向けの OpenAPI
- dashboard 上のテスト
- 正規化された SOAP fault
要するに、「全員が委託先の癖を覚える」ではなく、「1 つの境界で吸収する」に変えることです。
SOAPless が効く場所
委託先の SOAP が固定されていても、社内の利用者には次を渡したい。そういう時に SOAPless は噛み合います。
- 安定した JSON の入口
- 1 つのテスト導線
- 1つのドキュメント
- WSDL refresh とオペレーション確認の場所
フロントエンド、cron、社内サービス、個別スクリプトに委託先仕様を散らすより、ずっと健全です。