SAP 项目的 Web 服务粒度？

Posted 2023-02-16

【中文标题】SAP 项目的 Web 服务粒度？

【英文标题】：Web-services granularity with SAP project?

【发布时间】：2009-10-07 16:33:22

【问题描述】：

在作为 SAP 之上的第三个应用程序通过 SOAP Web 服务扩展其功能的项目中，我想知道应该如何定义 Web 服务本身；我们应该实现十几个实现简单和原子操作的 Web 服务，还是很少的 Web 服务接受一堆参数并完成所有事情。

我对反馈和建议感兴趣，考虑到： - SAP netweaver 层的工作负载（并发 Web 服务的数量） - 第三次应用维护 - SAP 网络服务维护 - 网络负载（考虑 SOAP 信封和 http 请求） - 我可能没有想到的任何其他考虑因素

谢谢

产科。

【参考方案1】：

远离 SAP，我在定义 Web 服务接口时的第一个想法是粗粒度服务往往比繁忙的细粒度服务更合适。

这首先是因为每次调用的开销都比较大，因此较少的往返次数往往是可取的。 （例如，GetName、GetAddress、GetPhoneNumber 与 GetPersonInfo）

其次，如果存在我们希望服务拥有它的逻辑。我们不希望每个客户端都需要知道调用细粒度方法的顺序。否则我们最终会在每个客户端中重复逻辑。

我有一篇文章here 详细阐述了诸如此类的问题。

【讨论】：

感谢这些架构问题！

【参考方案2】：

我会遵循 SAP 铺平的道路：从创建像细粒度服务一样的 CRUD 开始。当您浏览SAP Enterprise Services Wiki 时，您会发现SAP 提供的大多数服务都是细粒度的。

假设您目前处于服务 API 的第一次迭代中，可以肯定的是，您不会在第一次尝试时获得正确的高级 API，而是必须将其扩展为越来越特殊无论如何，将来的情况。那么，为什么不从细粒度 API 开始，然后根据实际经验提供更高级别的 API - 就像 SAP 对组合服务所做的那样。

当然，性能是一个考虑因素，但如上所述：企业服务基础架构是久经考验的 ABAP 引擎的外壳，而且这个引擎很快。

【参考方案3】：

就 SAP netweaver 层的工作负载而言，这是一个问题。不应该。 sap abap 应用服务器是您将遇到的成熟平台。它可以很好地扩展并且可以承受任何负载，只要它在 cpu 中有一些东西（他有效地使用它）。

所以问题更多的是网络开销和维护。像 djna 我相信粗粒度是要走的路。但这并没有什么特别令人讨厌的地方。