SAP项目的Web服务粒度？

Question

在一个项目中，作为第三个应用程序在SAP之上，通过SOAP Web服务扩展其功能，我想知道如何定义Web服务本身;我们应该实施十几个实现简单和简单的网络服务吗？原子操作，或者很少有需要大量参数并完成所有操作的Web服务。

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

由于

OB。

Answer 1

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

这首先是因为每次通话的开销相对较大，因此往往更少往返。 （例如，GetName，GetAddress，GetPhoneNumber与GetPersonInfo）

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

我有一篇文章here，详细阐述了这个问题。

Answer 2

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

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

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

Answer 3

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

所以问题更多的是网络开销和维护。像djna我相信粗粒度是要走的路。但对此没有特别的了解。