在一个作为 SAP 之上的第三个应用程序通过 SOAP Web 服务扩展其功能的项目中，我想知道应该如何定义 Web 服务本身；我们应该实现十几个实现简单和原子操作的 Web 服务，还是很少有 Web 服务接受一堆参数并完成所有事情。
我对反馈和建议感兴趣，考虑到：
- SAP netweaver 层上的工作负载（并发 Web 服务的数量）
- 第三个应用程序维护
- SAP Web 服务维护
- 网络负载（考虑 SOAP 信封和 http 请求）
- 我可能的任何其他考虑没想到
谢谢
OB。
远离 SAP，我在定义 Web 服务接口时的第一个想法是粗粒度服务往往比繁忙的细粒度服务更合适。
这首先是因为每次调用的开销都比较大，所以较少的往返次数往往是可取的。（例如，GetName、GetAddress、GetPhoneNumber 与 GetPersonInfo）
其次，如果有逻辑，我们希望服务拥有它。我们不希望每个客户端都需要知道调用细粒度方法的顺序。否则，我们最终会在每个客户端中重复逻辑。
我这里有一篇文章详细阐述了诸如此类的问题。
我会沿着 SAP 铺平的道路前进：从创建像细粒度服务一样的 CRUD 开始。当您浏览SAP Enterprise Services Wiki时，您会发现 SAP 提供的大多数服务都是细粒度的。
假设您目前处于服务 API 的第一次迭代中，可以肯定的是，您不会在第一次尝试时获得正确的高级 API，而是必须针对越来越多的特殊情况进行扩展。反正未来。那么为什么不从细粒度的 API 开始，稍后根据实际经验提供更高级别的 API - 就像 SAP 对组合服务所做的那样。
当然，性能是一个考虑因素，但如上所述：企业服务基础架构是经过时间考验的 ABAP 引擎的外壳，而且这个引擎很快。
至于 SAP netweaver 层上的工作负载是一个问题。不应该。sap abap 应用服务器是您将遇到的成熟平台。它可以很好地扩展并且可以承受任何负载，只要它在 cpu 中有一些东西（他有效地使用它）。
所以问题更多的是网络开销和维护。像 djna 我相信粗粒度是要走的路。但没有什么特别令人讨厌的。