SAP项目的Web服务粒度？

Question

在一个作为SAP之上的第三方应用程序的项目中，通过SOAP Web服务扩展其功能，我想知道应该如何定义Web服务本身;我们是否应该实现几十个实现简单的原子动作的Web服务，或者只有极少数Web服务需要一堆参数并完成所有工作。

我感兴趣的反馈&建议考虑：
- 在SAP NetWeaver层上的工作负载（并发Web服务量）
- 第三APP维护
- SAP Web的服务维修
- 网络负载（考虑SOAP enveloppes & HTTP请求）
- 任何其他考虑我可能没有想到的

感谢

OB。

Answer 1

从SAP的概念出发，我在定义Web Service接口时首先想到的一点是，粗粒度服务往往比繁忙的细粒度服务更合适。

这首先是因为每次通话的开销都比较大，所以往返次数往往更少。 （例如，GetName，GetAddress，GetPhoneNumber与GetPersonInfo）

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

我有一篇文章here，它阐述了这样的问题。

Answer 2

至于SAP网络层的工作负载是一个问题。它不应该。 SAP ABAP应用程序服务器与您将遇到的一样成熟。它可以很好地扩展，并且可以承担任何负载，只要它在CPU中有效（它使用效率高）。

所以问题是更多的网络开销和维护。就像djna一样，我相信粗粒是最好的选择。但是没有什么特别的事情可以做到。

Answer 3

我只是沿着这条道路走下去，SAP铺平了道路：从创建CRUD开始，像细粒度服务一样。当你浏览SAP Enterprise Services Wiki时，你会发现SAP提供的大多数服务都是细粒度的。

假设您目前正处于您的服务API的第一次迭代中，可以肯定的是，您将无法在第一次尝试中获得正确的高级API，而是必须将其扩展为越来越多无论如何，在未来的特殊情况。那么为什么不从一个细粒度的API开始，并在之后提供一个基于现实世界体验的更高级别的API--就像SAP使用组合服务一样。

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