真实案例：用适配器流程+库封装SOAP回调受限时的轮询方案

这是一个”理论最佳方案在现实中撞墙、然后找到务实折中”的具体案例。某客户有一个过时、API脆弱的文档管理系统（DMS），最初的最佳实践方案是把DMS包装成独立服务、通过API对外暴露（对应[[流程间通信跨越边界调用活动只在边界内API调用才能跨边界]]中”API调用跨越边界”的做法），业务服务不必知道对方在用工作流引擎。但该客户的通信方式是SOAP，异步返回依赖SOAP回调，而每次SOAP回调都要单独配置防火墙规则；由于很多服务都要用文档存储，回调会产生大量循环通信链接，运维负担太重，客户因此拒绝了这个理论上最优的方案。他们转而选择轮询：业务服务每分钟主动询问文档存储服务处理进度，因为该场景里等待一分钟延迟完全可接受、额外轮询产生的负载也不是问题，好处是所有通信都单向指向文档存储服务，不需要开放回调端口。但轮询逻辑本身（询问→等待一分钟→再次询问……）会带来新的长期运行复杂度，如果每个要和DMS通信的业务流程都各自实现一遍轮询逻辑，会造成大量重复代码——于是他们把轮询逻辑单独提取成”文档存储适配器流程”，业务流程通过调用活动来调用它，再把这个适配器流程连同所有远程调用和数据转换所需的胶水代码一起打包成一个库，嵌入每个需要与DMS通信的业务服务中；各业务服务各自部署自己的适配器流程实例，但流程模型来自同一个共享库，减少了重复劳动。这个方案的代价是一种可容忍的部署耦合：适配器逻辑有重大变更时，所有引用该库的客户端都要更新——但因为这段逻辑只是为了克服SOAP回调限制的一小段轮询代码，作者认为这种程度的耦合是可以接受的；如果条件允许，仍应优先选择独立部署、可直接调用API的文档存储服务。